OS/2, eCS & ArcaOS - Technical > Applications

LIBC panic errors anyone?

(1/5) > >>

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