Re: panic: __mp_lock_held(sched_lock) 2013-DEC-27 snapshot
On Tue, Jan 28, 2014 at 09:02:31PM -0800, Philip Guenther wrote: On Tue, Jan 28, 2014 at 4:55 PM, patrick keshishian sids...@boxsoft.com wrote: 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!)? Note that a recent gdb is available in ports, devel/gdb which installs the binary as egdb. Maybe it doesnt know/have tweaks for all our specificities, but it's there. For having tried it on firefox, it didnt fare much better than the base one.. Landry
Re: panic: __mp_lock_held(sched_lock) 2013-DEC-27 snapshot
On Wed, Jan 29, 2014 at 07:50:34AM +0100, J??r??mie Courr??ges-Anglas wrote: patrick keshishian sids...@boxsoft.com writes: On Tue, Jan 28, 2014 at 09:02:31PM -0800, Philip Guenther wrote: On Tue, Jan 28, 2014 at 4:55 PM, patrick keshishian sids...@boxsoft.com wrote: 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. It sounds like you're not using dlsym as intended, then. If you used: void (*my_function)(void); my_function = dlsym(handle, target_function); if (my_function == NULL) oops(); (*my_function)(); Hi, That is what I am doing right now. This method, allows the main program to compile just fine as the storage is reserved for the my_function (in your example). While, I had initially hoped one could have objects (e.g., int types, or structs) defined in the yet-to-be-loaded .so object file, referenced in the main program sources, and be able get the main program to link; then at run time, the .so object is loaded, and symbols updated/ resolved, just like the (system) dynamic linker (implicitly) does at program start up. Thanks for all your replies! --patrick
Re: panic: __mp_lock_held(sched_lock) 2013-DEC-27 snapshot
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
Re: panic: __mp_lock_held(sched_lock) 2013-DEC-27 snapshot
On Tue, Jan 28, 2014 at 09:02:31PM -0800, Philip Guenther wrote: 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... 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
Re: panic: __mp_lock_held(sched_lock) 2013-DEC-27 snapshot
On Tue, Jan 28, 2014 at 10:31 PM, patrick keshishian sids...@boxsoft.com wrote: On Tue, Jan 28, 2014 at 09:02:31PM -0800, Philip Guenther wrote: .. 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. Undefined weak symbols are useful for testing for the presence of optional functionality loaded at the same time as the code with the reference to the weak symbol. If the code that may contain the symbol will be loaded later, using a weak symbol reference is fragile, as it is dependent on the order of operations and reputably can conflict with compiler optimizations on some platforms. Even Sun, who were quite in love with their dynamic linker, recommended against doing that (c.f. the Sun Linker and Libraries Guide). Philip Guenther
Re: panic: __mp_lock_held(sched_lock) 2013-DEC-27 snapshot
patrick keshishian sids...@boxsoft.com writes: On Tue, Jan 28, 2014 at 09:02:31PM -0800, Philip Guenther wrote: 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... 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. It sounds like you're not using dlsym as intended, then. If you used: void (*my_function)(void); my_function = dlsym(handle, target_function); if (my_function == NULL) oops(); (*my_function)(); then your program wouldn't need to reference target_function at all. [...] -- jca | PGP: 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE (previous: 0x06A11494 / 61DB D9A0 00A4 67CF 2A90 8961 6191 8FBF 06A1 1494)
