Bug 512624

we identified some problems in glibc/malloc routines, can you perhaps try after the next factory rebuild (next tuesday or so) with updated glibc?

glibc needs to have this in its changelog:
-------------------------------------------------------------------
Mon Jun  8 17:58:50 CEST 2009 - pbaudis@suse.cz

- Fix race condition in the mcheck free() hook [bnc#509398]

I will check then. More info, I had a DNS problem and firefox crashed continually.

Created attachment 298196 [details]
backtrace firefox crash

After upgrading MozillaFirefox  3.0.11-2.1 to MozillaFirefox 3.5b99-86.3 it crashes randomly. 
(Program received signal SIGABRT, Aborted)

I can confirm that the crash occurs whenever there is a slow network response for example if zypper is refreshing or a package download is taking place firefox will crash trying to load google even. I think the reason that this bug is not noticed by many is most testers have a faster internet connection than me.

Not receiving mail for this bug just testing.

Updated to glibc-2.10.1-3.15 with the appropriate changelog entry then opened up this bug report while zypper was doing a forced refresh and restoring the crashed session from earlier this morning simultaneously. The page it was crashing on earlier wouldn't stay open long enough for me to read it properly.

Crashed again, will start to debug again and supply further backtrace. I only updated the glibc suite.

After upgrade to glibc-2.10.1-3.15, MozillaFirefox-3.5b99-86.3 crashes with signal SIGABRT.

Program received signal SIGABRT, Aborted.
[Switching to Thread 0xa85ffb70 (LWP 24162)]
0xb7c3b0b5 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
64      ../nptl/sysdeps/unix/sysv/linux/raise.c: No existe el fichero o el directorio.
        in ../nptl/sysdeps/unix/sysv/linux/raise.c                                    
Current language:  auto; currently c                                                  
(gdb) bt                                                                              
#0  0xb7c3b0b5 in *__GI_raise (sig=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:64   
#1  0xb7c3c947 in *__GI_abort () at abort.c:88                                        
#2  0xb7c7d99b in malloc_printerr (action=2, str=0x6 <Address 0x6 out of bounds>, ptr=0xa06a0bb0) at malloc.c:6201
#3  0xb7c7f6d4 in free_check (mem=0xa06a0bb0, caller=0x9b8bbde0) at hooks.c:284                                   
#4  0xb7c82379 in *__GI___libc_free (mem=0x6) at malloc.c:3677                                                    
#5  0x9b8bbde0 in load_case_tables () at lib/util_unistr.c:143                                                    
#6  0x9b7a50b9 in nss_wins_init () at nsswitch/wins.c:101                                                         
#7  lookup_byname_backend () at nsswitch/wins.c:114                                                               
#8  _nss_wins_gethostbyname_r () at nsswitch/wins.c:347                                                           
#9  0xb7cf9d33 in __gethostbyname_r (name=0xa111e780 "www.imatech.es", resbuf=0xa85fee50, buffer=0xa85fee6c "\300\250\1!", buflen=1024, result=0xa85fee68, 
    h_errnop=0xa85fee64) at ../nss/getXXbyYY_r.c:253                                                                                                       
#10 0xb762dfe6 in PR_GetHostByName (name=0xa111e780 "www.imatech.es", buf=0xa1124800 "", bufsize=1024, hp=0xa1124c00) at prnetdb.c:722                     
#11 0xb762e457 in pr_GetAddrInfoByNameFB (flags=<value optimized out>, af=<value optimized out>, hostname=<value optimized out>) at prnetdb.c:1987         
#12 PR_GetAddrInfoByName (flags=<value optimized out>, af=<value optimized out>, hostname=<value optimized out>) at prnetdb.c:2016                         
#13 0xb68d9bcf in nsHostResolver::ThreadFunc (arg=0xb3a82580) at nsHostResolver.cpp:884                                                                    
#14 0xb763b990 in _pt_root (arg=0xa88e4f80) at ptthread.c:228                                                                                              
#15 0xb7f8a54c in start_thread (arg=0x0) at pthread_create.c:297                                                                                           
#16 0xb7f8a480 in ?? () at pthread_create.c:216 from /lib/libpthread.so.0                                                                                  
#17 0x00000000 in ?? ()                                                                                                                                    
(gdb)

Created attachment 298625 [details]
Crash backtrace after new glibc

I see that firefox is already at firefox-3.5rc1

I've built my own firefox-3.5rc1 but it starts with the name Shiretoko. I'm not sure if I'm going to prove anything by running it. It looks like firefox.

Shiretoko / firefox just crashed again, I've started to debug it and will upload a back trace.

Just updated firefox and libraries to latest factory MozillaFirefox-3.5b99-1.2 along with the matching mozilla-xulrunner191-1.9.1b99-2.2.
My reasoning being the firefox I built myself was built against my existing libraries and still crashed which increases the probability of the bug being outside of the firefox package and in another library.

(In reply to comment #13)

[...]
> My reasoning being the firefox I built myself was built against my existing
> libraries and still crashed which increases the probability of the bug being
> outside of the firefox package and in another library.

The same problem happens to me also with seamonkey2 (seamonkey-2.0a3-11.1)

Created attachment 299406 [details]
Backtrace from gdb after upgrade to 3.5b99-1.2

Included in this backtrace are gdb messages about no debug source for libraries that load immediately before the crash. After installing the debug source that was available and updating the matching packages the backtrace was identical.
The libraries libldap-2.4.so.2,liblber-2.4.so.2, libgssapi_krb5.so.2, libkrb5.so.3, libk5crypto.so.3, libcom_err.so.2, libkeyutils.so.1, libsasl2.so.2 and libkrb5support.so.0 only appeared immediately  before the crash.
Maybe this is a clue?

Going to try firefox 3.5rc2 from mozilla ftp site. I've searched bugzilla.mozilla.org and haven't found anything like this bug, the closest match was for windows.

I think that's a dupe of bug 503151 :-(

Indeed it is. :-(

*** This bug has been marked as a duplicate of bug 503151 ***