Opened 13 years ago

Closed 13 years ago

Last modified 13 years ago

#5461 closed bug (invalid)

runtime_loader crash?

Reported by: kaliber Owned by: bonefish
Priority: normal Milestone: R1
Component: System/runtime_loader Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Platform: All


Any ideas what's wrong or how to debug? There are no errors in syslog, and runtime_loader is compiled with debug enabled.

(gdb) run
Starting program: /boot/common/lib/ooo-3.2/program/soffice.bin 

Program received signal SIGCONT, Continued.
[Switching to team /boot/common/lib/ooo-3.2/program/soffice.bin (2018) thread pthread func (2020)]
0x00000000 in ?? ()
(gdb) thread apply all bt

Thread 2 (team /boot/common/lib/ooo-3.2/program/soffice.bin (2018) thread pthread func (2020)):
#0  0x00000000 in ?? ()

Thread 1 (team /boot/common/lib/ooo-3.2/program/soffice.bin (2018) thread soffice.bin (2018)):
#0  0xffff0114 in ?? ()
#1  0x001012b9 in relocate_image (rootImage=0x137d90, image=0x137d90) at src/system/runtime_loader/elf.cpp:205
#2  0x00101339 in relocate_dependencies (image=0x137d90) at src/system/runtime_loader/elf.cpp:222
#3  0x0010182b in load_library (path=0x7ffee918 "/boot/common/lib/ooo-3.2/basis3.2/program/", flags=0, addOn=false, 
    _handle=0x7ffee8c0) at src/system/runtime_loader/elf.cpp:545
#4  0x00105281 in export_load_library (name=0x7ffee918 "/boot/common/lib/ooo-3.2/basis3.2/program/", flags=0, 
    _handle=0x7ffee8c0) at src/system/runtime_loader/export.cpp:34
#5  0x004374a4 in dlopen () from /boot/system/lib/
#6  0x0021c029 in osl_psz_loadModule (pszModuleName=0x7ffee918 "/boot/common/lib/ooo-3.2/basis3.2/program/", 
    nRtldMode=Variable "nRtldMode" is not available.
) at module.c:117
#7  0x0021c0a5 in osl_loadModule (ustrModuleName=0x18036c60, nRtldMode=0) at module.c:95
#8  0x00218bcd in osl_loadModuleRelative (baseModule=0x14efc9b <tryInstance>, relativePath=0x1803b050, mode=0)
    at /ooox/ooo-build-
#9  0x014efc1d in get_desktop_environment () at /ooox/ooo-build-
#10 0x014efe3e in autodetect_plugin () at /ooox/ooo-build-
#11 0x014f0075 in CreateSalInstance () at /ooox/ooo-build-
#12 0x01301f13 in InitVCL (rSMgr=@0x7ffeeea8) at /ooox/ooo-build-
#13 0x013022f0 in ImplSVMain () at /ooox/ooo-build-
#14 0x013024aa in SVMain () at /ooox/ooo-build-
#15 0x003f468d in soffice_main () at /ooox/ooo-build-
#16 0x00200f0a in main (argc=1053369, argv=0x6984) at main.c:38
#0  0x00000000 in ?? ()

Change History (2)

comment:1 by bonefish, 13 years ago

Resolution: invalid
Status: newclosed

So far I see no problem. Unlike on other platforms threads on Haiku are created in suspended state, which is why a SIGCONT has to be sent to them to start running. Apparently gdb stops when a SIGCONT is received, which is what you see here. Just "cont" the thread and the party will go on.

The other (main) thread is waiting, since it has just loaded a library and is notifying the debugger about that. The thread blocks until it gets a reply. With gdb being single-threaded this doesn't happen while it is waiting for input, though.

comment:2 by kaliber, 13 years ago

Thank you for your advice. That was helpful. Now, I saw a real problem. Something is wrong with pthread_cond_wait.

Note: See TracTickets for help on using tickets.