bonsai/harakit
5
4
Fork 3
Code Issues 37 Pull Requests 7 Projects 1 Releases 30 Activity

dj(1) segfault fix #134

Closed
trinity wants to merge 0 commits from dj into main
pull from: dj
merge into: bonsai:main
Conversation 8 Commits - Files Changed -
trinity commented 2024-07-03 14:24:19 -06:00
Owner
Copy Link
  • dj(1) is now littered with assertions for future bug report help
  • fixes #112
  • "hard" skips and seeks (without lseek(3p)) are reported in the diagnostics
  • considerable refactoring
  • updated docs
+ dj(1) is now littered with assertions for future bug report help + fixes #112 + "hard" skips and seeks (without lseek(3p)) are reported in the diagnostics + considerable refactoring + updated docs
trinity added the
bug
 label 2024-07-03 14:24:19 -06:00
trinity added 2 commits 2024-07-03 14:24:20 -06:00
trinity added 2 commits 2024-07-03 14:50:58 -06:00
trinity commented 2024-07-03 14:53:05 -06:00
Author
Owner
Copy Link

@emma could you verify #112 is fixed on this branch?

@emma could you verify #112 is fixed on this branch?
trinity requested review from emma 2024-07-03 14:53:16 -06:00
trinity requested review from silt 2024-07-03 14:53:16 -06:00
trinity changed title from WIP: dj(1) segfault fix to dj(1) segfault fix 2024-07-03 14:53:24 -06:00
emma approved these changes 2024-07-03 15:36:16 -06:00
Dismissed
trinity added 5 commits 2024-07-03 16:13:29 -06:00
trinity requested review from emma 2024-07-03 16:14:37 -06:00
emma requested changes 2024-07-03 16:22:19 -06:00
Dismissed
docs/dj.1 Outdated
@ -36,3 +36,3 @@
When seeking or skipping to a byte, writing or reading starts at the byte
immediately subsequent to the specified byte.
immediately subsequent to the specified byte. Seeks and skips aren\(cqt counted
emma commented 2024-07-03 16:21:32 -06:00
Owner
Copy Link

Isn’t this not the case anymore? I thought we write at the byte specified, now.

Isn’t this not the case anymore? I thought we write at the byte specified, now.
trinity marked this conversation as resolved
trinity added 3 commits 2024-07-03 18:31:39 -06:00
trinity requested review from emma 2024-07-03 18:31:57 -06:00
trinity added 1 commit 2024-07-03 18:44:54 -06:00
trinity added 2 commits 2024-07-03 19:07:44 -06:00
trinity added 1 commit 2024-07-03 19:22:51 -06:00
trinity added 1 commit 2024-07-03 20:52:52 -06:00
trinity added 5 commits 2024-07-04 19:46:02 -06:00
trinity added 7 commits 2024-07-04 21:32:29 -06:00
trinity added 1 commit 2024-07-05 08:06:52 -06:00
trinity commented 2024-07-05 08:17:37 -06:00
Author
Owner
Copy Link

I think this is the best dj(1) can be, at least until we spot another bug. #94 will let us move out that parse() routine which will be nice.

I'm happy with the code size, especially relative to functionality which is much improved. Many of the little nits have been picked.

I think this is the best dj(1) can be, at least until we spot another bug. #94 will let us move out that parse() routine which will be nice. I'm happy with the code size, especially relative to functionality which is much improved. Many of the little nits have been picked.
emma commented 2024-07-07 17:50:17 -06:00
Owner
Copy Link
$ build/bin/dj -o /dev/full
meow meow meow
build/bin/dj: Partial read:
	0100150010015-2

No error message to alert the user that the device has no storage left. Please handle the error in writing to an output.

``` $ build/bin/dj -o /dev/full meow meow meow build/bin/dj: Partial read: 0100150010015-2 ``` No error message to alert the user that the device has no storage left. Please handle the error in writing to an output.
trinity commented 2024-07-07 18:07:21 -06:00
Author
Owner
Copy Link

Please comment with the output with -H.

On OpenBSD, write(2) doesn't error (by returning -1) on /dev/full - writing "meow\n" to /dev/full apparently succeeds, returning 5 (the expected number of bytes written).

dd(1) on OpenBSD exhibits the same behavior:

# printf 'meow\n' | dd of=/dev/full
0+1 records in
0+1 records out
5 bytes transferred in 0.000 secs (40922 bytes/sec)

I had to $ cat </dev/full to realize the pseudodevice doesn't exist on OpenBSD. It looks like the write succeeded on your system, too? What's your $ uname -a?

Please comment with the output with -H. On OpenBSD, write(2) doesn't error (by returning -1) on /dev/full - writing "meow\n" to /dev/full apparently succeeds, returning 5 (the expected number of bytes written). dd(1) on OpenBSD exhibits the same behavior: ``` # printf 'meow\n' | dd of=/dev/full 0+1 records in 0+1 records out 5 bytes transferred in 0.000 secs (40922 bytes/sec) ``` I had to `$ cat </dev/full` to realize the pseudodevice doesn't exist on OpenBSD. It looks like the write succeeded on your system, too? What's your `$ uname -a`?
trinity added 1 commit 2024-07-07 18:15:08 -06:00
emma commented 2024-07-07 18:15:12 -06:00
Owner
Copy Link
$ uname -a             
Linux noire-carnation 6.9.7-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 28 Jun 2024 18:11:28 +0000 x86_64 GNU/Linux
$ build/bin/dj -Ho /dev/full
meow meowm oew
build/bin/dj: Partial read:
	0+1 > 0+0; 15 > 0
0+1 > 0+0; 15 > -2
``` $ uname -a Linux noire-carnation 6.9.7-artix1-1 #1 SMP PREEMPT_DYNAMIC Fri, 28 Jun 2024 18:11:28 +0000 x86_64 GNU/Linux $ build/bin/dj -Ho /dev/full meow meowm oew build/bin/dj: Partial read: 0+1 > 0+0; 15 > 0 0+1 > 0+0; 15 > -2 ```
trinity commented 2024-07-07 18:16:24 -06:00
Author
Owner
Copy Link

Along these lines I did notice a bug in the write functionality that is now fixed. Judging from your dj(1) statistics it wasn't, but you may want to try again anyway.

Along these lines I did notice a bug in the write functionality that is now fixed. Judging from your dj(1) statistics it wasn't, but you may want to try again anyway.
trinity added 1 commit 2024-07-07 20:34:13 -06:00
trinity commented 2024-07-07 21:14:18 -06:00
Author
Owner
Copy Link

Give it another whirl.

Give it another whirl.
trinity added 1 commit 2024-07-07 21:15:19 -06:00
emma approved these changes 2024-07-07 23:41:21 -06:00
trinity commented 2024-07-08 11:21:35 -06:00
Author
Owner
Copy Link

Merged.

Merged.
trinity closed this pull request 2024-07-08 11:24:20 -06:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
silt
emma
Labels
Clear labels   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
joke

you are silly!

  
question

More information is needed

  
wontfix

This won't be fixed

No Label
bug
duplicate
enhancement
help wanted
invalid
joke
question
wontfix
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: bonsai/harakit#134
No description provided.
Delete Branch "dj"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?