localtime() dllcc calls hang

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

localtime() dllcc calls hang

Jan Weerts
Hi everyone!

We have strange deadlocks, when accessing locale dependent
time functions in libc on linux and solaris. Strangest thing
about it is, that it does *not* occur in a deterministic
manner, i.e. sometimes it works, sometimes the application
or the development image freezes.

The freeze never occurs, when the machines timezone is set
to UTC, but in our case it is set to CEST. We currently use
the OSTimeZone package available in the public repository
and encounter the problem while calling functions that
internally call tzset_internal().

When attaching with gdb under linux, we usually receive a
trace similar to the one attached at the end of this mail.
After the line containing "Continuing" we execute
"UnixTimeSupport osNow" in the image. Upon deadlock we
interrupt in gdb and have the presented stack trace. We
don't know which other resource might block that mutex.

We already tried:
- changing the ExternalInterface library declaration
    #(#libraryFiles #('libc.so.6' 'libc.so' 'libc.sl' 'libc.a(shr.o)'))
    #(#libraryDirectories #('/lib' '/usr/shlib' '/usr/lib'))
  to arbitrary values, like no #libraryDirectories or platform
  dependent entries

- changing the ExternalInterface declaration to force a
  rebinding of libraries

- issueing a "UnixTimeSupport unloadLibraries" beforehand

- testing in a vanilla image vs. full blown development image

- saving the image once on every platform

and some combinations thereof...

Any help appreciated!

Regards
  Jan

two sidenotes:
- why is it necessary reference libc at all, since the vm
  itself is already linked against it and therefore could
  resolve the symbols?

- #findFile:inDirectories: receives the data from the above
  #libraryFiles and #libraryDirectories entries, but platform
  dependent #libraryFiles entries only work, when also at
  least one #libraryDirectories entry exists. Not nice.

-------------------------------------------------------------------

VisualWorks version: VisualWorks, 7.4 of December 5, 2005

Linux: Kernel 2.6.13-15-default, glibc 2.3.5

gdb dump:
> ../vw7.4/bin/linux86/vwlinux86gui image.im &
[1] 6357
> gdb ../vw7.4/bin/linux86/vwlinux86gui --pid=6357
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i586-suse-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

Attaching to program: /home/user/vw7.4/bin/linux86/vwlinux86gui, process 6357
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
Reading symbols from /lib/tls/libpthread.so.0...done.
[Thread debugging using libthread_db enabled]
[New Thread 1076473088 (LWP 6357)]
Loaded symbols for /lib/tls/libpthread.so.0
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /usr/X11R6/lib/libX11.so.6...done.
Loaded symbols for /usr/X11R6/lib/libX11.so.6
Reading symbols from /lib/tls/libm.so.6...done.
Loaded symbols for /lib/tls/libm.so.6
Reading symbols from /lib/libz.so.1...done.
Loaded symbols for /lib/libz.so.1
Reading symbols from /lib/tls/libc.so.6...done.
Loaded symbols for /lib/tls/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2...done.
Loaded symbols for /usr/X11R6/lib/X11/locale/lib/common/xlcUTF8Load.so.2
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /usr/X11R6/lib/libXcursor.so.1...done.
Loaded symbols for /usr/X11R6/lib/libXcursor.so.1
Reading symbols from /usr/X11R6/lib/libXrender.so.1...done.
Loaded symbols for /usr/X11R6/lib/libXrender.so.1
Reading symbols from /usr/X11R6/lib/libXext.so.6...done.
Loaded symbols for /usr/X11R6/lib/libXext.so.6
0xffffe410 in __kernel_vsyscall ()
(gdb) continue
Continuing.

------ "UnixTimeSupport osNow" doit ------

Program received signal SIGINT, Interrupt.
[Switching to Thread 1076473088 (LWP 6357)]
0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0  0xffffe410 in __kernel_vsyscall ()
#1  0x4003c13e in __lll_mutex_lock_wait () from /lib/tls/libpthread.so.0
#2  0x4003d807 in _L_mutex_lock_25 () from /lib/tls/libpthread.so.0
#3  0x0c354270 in ?? ()
#4  0x00000001 in ?? ()
#5  0xbfab9310 in ?? ()
#6  0x40b8ea58 in _IO_link_in_internal () from /lib/libc.so.6
#7  0x40b8ea58 in _IO_link_in_internal () from /lib/libc.so.6
#8  0x40b8c316 in _IO_new_file_init () from /lib/libc.so.6
#9  0x40b836dc in __fopen_internal () from /lib/libc.so.6
#10 0x40b8374d in fopen@@GLIBC_2.1 () from /lib/libc.so.6
#11 0x40bacb35 in __tzfile_read () from /lib/libc.so.6
#12 0x40bab7f5 in tzset_internal () from /lib/libc.so.6
#13 0x40bac3bb in tzset () from /lib/libc.so.6
#14 0x080c3093 in pdCallC (specifierMask=18, oThis=0x0, oHandle=0xfffffffc,
    argumentKinds=0xb787bf9 "", numArgs=0, regArgs=2, poArguments=0xbfacb33c,
    structArgsSize=0, returnKindSize=0, pErrorType=0xbfab9604)
    at linux86CallC.c:381
#15 0x0805c583 in primCallVarArgC (oReceiver=0x8514674, numArgs=0,
    poArguments=0xbfacb33c) at exCallC.c:516
#16 0x080a67c8 in rtPrimGlueVarArgMany ()
#17 0x08514674 in ?? ()
#18 0x00000000 in ?? ()
#19 0xbfacb33c in ?? ()
#20 0xbfab9654 in ?? ()
#21 0x00000000 in ?? ()
#22 0x00000000 in ?? ()
#23 0x080fd328 in ?? ()
#24 0x00000002 in ?? ()
#25 0x08088f1f in launchSystem () at mmInit.c:506
#26 0x08360cd9 in ?? ()
#27 0x08c2103c in ?? ()