OS/2, eCS & ArcaOS - Technical > Applications
LIBC panic errors anyone?
Dariusz Piatkowski:
I am running the following LIBC RPM packages:
1) libc.pentium4 1:0.1.9-1.oc00
2) libc-devel.pentium4 1:0.1.9-1.oc00
3) libcurl.pentium4 7.75.0-2.oc00
4) libcx.pentium4 0.7.2-1.oc00
5) libcx-devel.pentium4 0.7.2-1.oc00
...and at some point in time (along the upgrade path) I started to notice the following "LIBC PANIC" errors in my trp directory:
--- Quote --- LIBC PANIC!! _um_free_maybe_lock: Tried to free block twice - block=37013a00 lo
...
Call Stack
______________________________________________________________________
EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 1FE4B89E LIBCN0 0001:000FB89E
0013EAF8 1FE4C0A8 LIBCN0 0001:000FC0A8
0013EB18 1FDE4B69 LIBCN0 0001:00094B69
0013EB68 1FDC4D69 LIBCN0 0001:00074D69
0013EB88 7B395268 XUL 0001:03565268 between js::gc::Arena::finalize + 228 and js::gc::ArenaLists::backgroundFinalize - 3678 (both in Unified_cpp_js_src23.cpp)
34734D20 344B0538 *Unknown*
Lost Stack chain - new EBP below previous
...
--- End quote ---
This one was actually generated by FF following my upgrade to the latest NSPR and NSS runtimes.
However, I've seen this error repeatedly with other applications, such as:
CRON/2:
--- Quote --- LIBC PANIC!! _um_free_maybe_lock: Tried to free block twice - block=20030035 lo
...
Call Stack
_____________________________________________________________________
EBP Address Module Obj:Offset Nearest Public Symbol
-------- --------- -------- ------------- -----------------------
Trap -> 1FE4B89E LIBCN0 0001:000FB89E
0012FF14 1FE4C0A8 LIBCN0 0001:000FC0A8
0012FF34 1FDE4B69 LIBCN0 0001:00094B69
0012FF84 1FDC4D69 LIBCN0 0001:00074D69
0012FFA4 000100E0 CRON2 0001:000000E0
0012FFC4 00014238 CRON2 0001:00004238
0012FFF4 1FFECE38 DOSCALL1 0004:0000CE38 DOS32R3EXITADDR
...
--- End quote ---
...or PMMail and AOO.
So I'm curious if anyone is seeing this too?
I can't quite peg this to a particular release, but it would have happened within the last couple of drops I think?
Dave Yeo:
Yes, it became very common about the time that the latest NSPR4 and NSS were moved to netlabs-rel along with a bunch of other stuff including libc and libcx. Mostly I see them with SeaMonkey.
David McKenna:
Dariusz,
I also see these frequently with SeaMonkey, but so far not with any other software (I do use PMMail and AOO).
Regards,
Jochen Schäfer:
I noticed that problem while using lsusb.
Lars:
Yes, I have also seen this trap report:
Don't shoot the messenger. It looks like there is an actual improvement in libc to properly report if you call "free" on the very same pointer more than once (which is forbidden).
Consequently, that likely means that the affected applications actually have a problem managing their dynamic memory. These problems can go unnoticed if for example a memory page is not directly assigned to another allocation and therefore remains accessible for some time. That's why it is so important to report this error.
About lsusb: if you see them in LIBUSB, then that's the reason why I am still working on it :-)
Cheers,
Lars
Navigation
[0] Message Index
[#] Next page
Go to full version