abrt 1.0.8 detected a crash. architecture: x86_64 cmdline: /usr/lib64/firefox-3.5.8/firefox comment: I removed most of the backtrace because I do not want to look through the tons of lines to find confidential data. If it will be helpful, I can do this, though, or try to reproduce this. component: firefox executable: /usr/lib64/firefox-3.5.8/firefox kernel: 2.6.32.9-70.fc12.x86_64 package: firefox-3.5.8-1.fc12 rating: 4 reason: Process /usr/lib64/firefox-3.5.8/firefox was killed by signal 11 (SIGSEGV) release: Fedora release 12 (Constantine) backtrace ----- [New Thread 3708] [New Thread 3767] [New Thread 3789] [New Thread 3796] [New Thread 4993] [New Thread 3713] [New Thread 3788] [New Thread 3838] Core was generated by `/usr/lib64/firefox-3.5.8/firefox'. Program terminated with signal 11, Segmentation fault. #0 0x000000327e80efbb in raise (sig=<value optimized out>) at ../nptl/sysdeps/unix/sysv/linux/pt-raise.c:42 42 sig); Thread 9 (Thread 3838): #0 0x000000327e0d51e3 in __poll (fds=<value optimized out>, nfds=<value optimized out>, timeout=<value optimized out>) at ../sysdeps/unix/sysv/linux/poll.c:87 _a3 = -1 _a1 = 140379825367584 resultvar = <value optimized out> _a2 = 1 resultvar = <value optimized out> oldtype = 0 result = <value optimized out> #1 0x0000003a60a2573f in ?? () from /lib64/libnspr4.so No symbol table info available. #2 0x000000317c8f8a55 in nsSocketTransportService::Poll ( this=<value optimized out>, wait=<value optimized out>, interval= 0x7facb99fecbc) at nsSocketTransportService2.cpp:355 rv = 1 pollList = 0x7facbeff89c0 pollCount = 1 pollTimeout = 4294967295 ts = 1996861026 passedInterval = <value optimized out> How to reproduce ----- 1. firefox crashed after I wanted to add an attachment to a new bug report before I submitted the bug report. I selected a file and after I closed the dialog, it crashed.
Created attachment 401266 [details] File: backtrace
The back-trace you submitted is not complete enough to begin to isolate the cause. If you wish, open your back-trace and search for the word signal. When you see the line that contains the string <signal handler called> Then just go through THAT particular thread for confidential information. That is the thread we would need. If you are willing to send your entire back-trace so that only the developers can see it, when you attach it, mark it as private. Even I (I am a volunteer triager) can not see a private attachment. Only certain redhat employees (as far as i know) can see them. Either way, as it stands now, I would have to close this as INSUFFICIENT_DATA due to not having enough information to being the troubleshooting process. Let us know.. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers