[illumos-gate] 16634 nvme: nvme_cq_t.ncq_tail is unused -- Andy Fiddaman <illumos⊙fn>

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?

kill(0, ... ) maybe? but I need to be able continue it once I attach with a debugger.

SIGSTOP?

Are you from outside the process?

It's not really the same as pstop under the hood, but semantically probably close.

I'll try that.

kill(0, SIGSTOP)

Otherwise, you can just use the stable /proc APIs.

I think I had trouble getting the debugger to connect though, last time I tried that.

Do you need to know synchronously that this has happened?

Nah, this is just a startup hack.

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.

I guess it sorta works to: (1) attach gdb, (2) outside of gdb do "kill -CONT $pid", (3) in gdb "continue"

But gdb seems to be still confused. I think maybe I need to tell gdb to leave SIGCONT alone.

bummer. gdb is hopelessly confused. Keeps continuing the program with SIGSTOP.

[illumos-gate] 16606 Add support for additional log pages to SATL -- Jason King <jason.brian.king⊙gc>

I have been having issues with gcc and signals on omnios bloody

sorry, _gdb_ and signals

so many issues, so many matching /g../

I haven't been able to figure out any better what's actually happening though, just "very weird" and "signals"

(it crashes at the end, rather than misbehaving though)

My program seems to restart the: kill(0, SIGSTOP)

I'm not sure how to avoid that. I wonder if pause(2) would work?

Is this basically a you want the process to stop running until you attach with gdb?

And is modding the target allowed?

right.

gwr: so my problem is that if I send SIGINT, I receive SIGINT in a loop until I crash

are you saying you receive SIGSTOP more than once, by any chance?

Just do the dumb thing of while (var) { sleep(1s); }' and mod var?

I can attach, but continue leave it continually SIGCONT itself. (Not sure if gdb does that or if the restarts the kill call)

Yes, gdb keeps reporting SIGSTOP

huh, that's at least similar in spirit to wwhat's screwing me

I reported omniosorg/omnios-extra #1476

I wonder if pstop would work? but I don't have libproc is this monster.

is/in

An old bug, but looks relevant: gdb-prs.sourceware.narkive.com/zyvn…igstop-handling-is-counterintuitive

Looking at the gdb code, STOP_QUIETLY_NO_SIGSTOP is supposed to deal with this.

gwr: Might be fun to implement phang(1)!

I should probably file a bug somewhere about gdb. That's supposed to work (attaching to a process that was stopped with SIGSTOP)

surely you mean it might be phun? :)

Yeah, maybe I'll go work on that next time I'm bored.

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 sourceware.org/git/?p=binutils-gdb.…63e5dbb99cbfdd1c5385e53ed031ff#l923

@richlowe might be interested

Maybe attaching to a process that's stopped that way needs special handling.

And maybe on detach, offer to leave it stopped, but I don't care about that :)