On Tue, Jan 28, 2014 at 09:02:31PM -0800, Philip Guenther wrote: > On Tue, Jan 28, 2014 at 4:55 PM, patrick keshishian <[email protected]> > 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...
Thanks. > > 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. A bit of a chicken-and-egg situation for this case. Unless I do some ugly "hopping" around in Makefiles, it would be difficult to include the object on the link line for the main program. > 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. Yes. I do that right now with a bit of "dance". However, reading a bit about __attribute__((weak)) on-line, I thought, there may be an easier way to achieve this. But, I quite possibly misunderstood the use of that attribute. Thanks again, --patrick > 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 >
