17:17:18 [illumos-gate] 16634 nvme: nvme_cq_t.ncq_tail is unused -- Andy Fiddaman 18:10:35 Assuming I don't have an easy way to call libproc stuff or run commands (just libc calls) what's the simplest way to make a process put itself to sleep like "pstop" would? suggestions? 18:11:15 kill(0, ... ) maybe? but I need to be able continue it once I attach with a debugger. 18:13:50 SIGSTOP? 18:14:03 Are you from outside the process? 18:15:06 It's not really the same as pstop under the hood, but semantically probably close. 18:15:08 I'll try that. 18:15:21 kill(0, SIGSTOP) 18:15:28 Otherwise, you can just use the stable /proc APIs. 18:15:41 I think I had trouble getting the debugger to connect though, last time I tried that. 18:15:50 Do you need to know synchronously that this has happened? 18:16:35 Nah, this is just a startup hack. 19:05:28 Yeah, I remember running into this previously. gdb gets confused trying to continue a process that we attach to after it does 'kill(0, SIGSTOP)' to itself. 19:06:58 I guess it sorta works to: (1) attach gdb, (2) outside of gdb do "kill -CONT $pid", (3) in gdb "continue" 19:09:57 But gdb seems to be still confused. I think maybe I need to tell gdb to leave SIGCONT alone. 19:11:20 bummer. gdb is hopelessly confused. Keeps continuing the program with SIGSTOP. 19:15:32 [illumos-gate] 16606 Add support for additional log pages to SATL -- Jason King 19:19:10 I have been having issues with gcc and signals on omnios bloody 19:19:24 sorry, _gdb_ and signals 19:19:35 so many issues, so many matching /g../ 19:20:00 I haven't been able to figure out any better what's actually happening though, just "very weird" and "signals" 19:20:07 (it crashes at the end, rather than misbehaving though) 19:20:39 My program seems to restart the: kill(0, SIGSTOP) 19:21:12 I'm not sure how to avoid that. I wonder if pause(2) would work? 19:22:04 Is this basically a you want the process to stop running until you attach with gdb? 19:22:29 And is modding the target allowed? 19:22:37 right. 19:23:08 gwr: so my problem is that if I send SIGINT, I receive SIGINT in a loop until I crash 19:23:18 are you saying you receive SIGSTOP more than once, by any chance? 19:23:19 Just do the dumb thing of while (var) { sleep(1s); }' and mod var? 19:23:33 I can attach, but continue leave it continually SIGCONT itself. (Not sure if gdb does that or if the restarts the kill call) 19:24:01 Yes, gdb keeps reporting SIGSTOP 19:24:12 huh, that's at least similar in spirit to wwhat's screwing me 19:24:39 I reported https://github.com/omniosorg/omnios-extra/issues/1476 19:33:51 I wonder if pstop would work? but I don't have libproc is this monster. 19:34:01 is/in 19:41:35 An old bug, but looks relevant: https://gdb-prs.sourceware.narkive.com/zyvnUblz/bug-gdb-17024-new-sigstop-handling-is-counterintuitive 20:07:47 Looking at the gdb code, STOP_QUIETLY_NO_SIGSTOP is supposed to deal with this. 20:16:21 gwr: Might be fun to implement phang(1)! 20:28:01 I should probably file a bug somewhere about gdb. That's supposed to work (attaching to a process that was stopped with SIGSTOP) 20:35:38 surely you mean it might be phun? :) 21:58:06 Yeah, maybe I'll go work on that next time I'm bored. 22:32:48 I haven't tried yet, but I think if we attach to a process that has stopped with kill(0, SIGSTOP), this code will continue it with that signal forever more. right? See proc_run_process in https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gdb/procfs.c;h=48e9f3dd4b5f422d6749672098a5a4bcc59fbc1e;hb=02c10eaecb63e5dbb99cbfdd1c5385e53ed031ff#l923 22:33:17 @richlowe might be interested 22:34:11 Maybe attaching to a process that's stopped that way needs special handling. 22:34:50 And maybe on detach, offer to leave it stopped, but I don't care about that :)