On Tue, Jan 28, 2014 at 4:55 PM, patrick keshishian <sids...@boxsoft.com> wrote: > Not sure if anyone is interested in this panic as the > snapshot is a bit old. > > Happend while gdb-ing a process. > > (typing off images; expect typos) > > login: panic: kernel diagnostic assertion "__mp_lock_held(&sched_lock) == 0" > failed: file "../../../../lock.c", line 126
That's the bug I was working on at the start of the n2k14 hackathon. I've managed to simplify some of the bits underneath it, so maybe I can get the intermediate problem (recursive tsleep() usage) resolved... > Side note 1: > Incidentally, I couldn't figure out how to correctly leave > a symbol unresolved while compiling myapp, until dlopen() > time. If you can include the shared-object/library in the link command line, then the symbol can be referenced at link time. That lets you refer to the symbols directly as if they were in the executable itself, though you must still declare them for the compiler to know what type they are, etc. If you need to delay the loading of the shared-object until after process startup via dlopen(), then the executable should use dlsym() to get the symbol address, passing it the handle that dlopen() returned. c.f. the dlsym(3) manpage for details and other possbilities. > Side note 2: > I see gdb crash quite often on subsequent run of app being > debugged. I've noticed this on a bunch of snapshots dating > some months back. Never reported it cause, I don't have a > simple test-case to submit, and things have been moving > fast with what you guys are doing. gdb has had many bugs in the past. Many are fixed in versions newer than the version that are shipped with OpenBSD, but licensing keeps us from including them in general. :-/ Anyone care to hack on gdb (no copying GPLv3 source!)? Philip Guenther
