I tested with a locally created TB.
I created a working copy of TB from local updated M-C/C-C (with only minipal patches created locally so as not to disturb the TB operation).
So this may be even newer than Daily available on the web.
As I learned a couple of years back, I can specify the mbox/maildir selection when the new account is created.
(And if I specify maildir, TB needed to restart).
Well, I received about 180 messages from locally running daemons. (This was tested under local linux machine. Actually a linux image inside virtualbox.)
I repeated copying the repeated messages to a newly created empty directory.
After the message count exceeded 1000+, there was no problem.
I did something similar by copying this 1000+ messages at once to a different folder.
Again, no problem.
But please note that such repated copying of 180+ messages may not trigger real world conditions since the message ID strings are repeated, the time/date sender/receiver information is repeated.
So I used the following short shell snipet to send myself a couple of thousand e-mails to see how this impacts TB.
```
$ for f in $(seq 1 2000)
> do
> echo "\ntest test" | mail -s "test subject $f" ishikawa
> done
```
Well actually "\ntest ..." is meaningless, it can be simply "test test".
Well, |mail| under Debian GNU/Linux prompts for "cc:" address when called interactively on the shell line, but it turns out,
it does not seem to ask so, if it is invoked as part of shell script (or rather the input is a piple).
So it sends 2000 e-mails to me and I thought I would obtain 2000 e-mails from that.
But then strangely, I only found I received 980 e-mails in TB in Inbox.
Something went wrong and TB is no longer able to receive the further e-mails.
I was not sure what was happening.
Trying to receive remaining e-mails from mail command invoked from the shell.
I got this message:
```
$mail
Cannot read mailbox /var/mail/ishikawa: Conflict with previous locker
```
and sure enough, there was "ishikawa.lock" file.
Who or rather which program has created this lock file. TB (?), most likely.
So thought I would finish TB and would try to see if the lock file would disappear.
Then I hit this crash at the program finish stage.
```
Hit MOZ_CRASH(mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction) at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:440
#01: ???[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so +0x616b5e9]
#02: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3ef67]
#03: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3f10a]
#04: __libc_start_main[/lib/x86_64-linux-gnu/libc.so.6 +0x277f4]
#05: _start[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird +0x162fa]
#06: ??? (???:???)
Program /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird (pid = 50352) received signal 11.
Stack:
#01: ???[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so +0x6604035]
#02: ???[/lib/x86_64-linux-gnu/libpthread.so.0 +0x13200]
#03: ???[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so +0x616b5f3]
#04: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3ef67]
#05: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3f10a]
#06: __libc_start_main[/lib/x86_64-linux-gnu/libc.so.6 +0x277f4]
#07: _start[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird +0x162fa]
#08: ??? (???:???)
Sleeping for 300 seconds.
Type 'gdb /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird 50352' to attach your debugger to this thread.
```
Ouch, so there could be a memory structure (List in this case), which may not be properly cleared, etc.
In a memory tight system, this could be a problem. I have 16GB memory assigned to virtualbox on a 32GB real memory PC.
When I looked at the stack using gdb, this is what I got.:
```
(gdb) where
#0 0x00007f290ce30335 in __GI___clock_nanosleep
(clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:43
#1 0x00007f290ce353f3 in __GI___nanosleep
(req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50)
at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007f290ce3532a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#3 0x00007f2904a28af9 in common_crap_handler(int, void const*)
(signum=11, aFirstFramePC=0x7f2904a03035 <nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)+197>) at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:95
#4 0x00007f2904a28b1d in ah_crap_handler(int) (signum=<optimized out>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:103
#5 0x00007f2904a03035 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)
(signo=11, info=0x7ffe9c2191b0, context=0x7ffe9c219080)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/profile/nsProfileLock.cpp:183
#6 0x00007f290d174200 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#7 MOZ_Crash
(aReason=0x55c9973b0e80 <sPrintfCrashReason> "mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction", aLine=440, aFilename=0x7f2906ef2370 "/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h") at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:261
#8 mozilla::LinkedList<nsSHistory>::~LinkedList() (this=<optimized out>, __in_chrg=<optimized out>)
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:440
--Type <RET> for more, q to quit, c to continue without paging--
#9 mozilla::LinkedList<nsSHistory>::~LinkedList() (this=<optimized out>, __in_chrg=<optimized out>)
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:437
#10 0x00007f290cda9f67 in __run_exit_handlers
(status=0, listp=0x7f290cf28738 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#11 0x00007f290cdaa10a in __GI_exit (status=<optimized out>) at exit.c:139
#12 0x00007f290cd927f4 in __libc_start_main (main=
0x55c99730ae90 <main(int, char**, char**)>, argc=2, argv=0x7ffe9c2197a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe9c219798) at ../csu/libc-start.c:366
#13 0x000055c99730b2fa in _start ()
(gdb) where
#0 0x00007f290ce30335 in __GI___clock_nanosleep
(clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:43
#1 0x00007f290ce353f3 in __GI___nanosleep
(req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50)
at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007f290ce3532a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#3 0x00007f2904a28af9 in common_crap_handler(int, void const*)
(signum=11, aFirstFramePC=0x7f2904a03035 <nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)+197>) at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:95
#4 0x00007f2904a28b1d in ah_crap_handler(int) (signum=<optimized out>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:103
#5 0x00007f2904a03035 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)
(signo=11, info=0x7ffe9c2191b0, context=0x7ffe9c219080)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/profile/nsProfileLock.cpp:183
#6 0x00007f290d174200 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#7 MOZ_Crash
(aReason=0x55c9973b0e80 <sPrintfCrashReason> "mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction", aLine=440, aFilename=0x7f2906ef2370 "/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h") at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:261
#8 mozilla::LinkedList<nsSHistory>::~LinkedList() (this=<optimized out>, __in_chrg=<optimized out>)
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:440
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb) up
#1 0x00007f290ce353f3 in __GI___nanosleep (req=req@entry=0x7ffe9c218f50,
rem=rem@entry=0x7ffe9c218f50) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
25 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) up
#2 0x00007f290ce3532a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
55 ../sysdeps/posix/sleep.c: No such file or directory.
(gdb) up
#3 0x00007f2904a28af9 in common_crap_handler (signum=11,
aFirstFramePC=0x7f2904a03035 <nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)+197>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:95
95 sleep(_gdb_sleep_duration);
(gdb) up
#4 0x00007f2904a28b1d in ah_crap_handler (signum=<optimized out>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:103
103 common_crap_handler(signum, CallerPC());
(gdb) up
#5 0x00007f2904a03035 in nsProfileLock::FatalSignalHandler (signo=11, info=0x7ffe9c2191b0,
context=0x7ffe9c219080)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/profile/nsProfileLock.cpp:183
183 oldact->sa_handler(signo);
(gdb) up
#6 <signal handler called>
(gdb) up
#7 MOZ_Crash (
aReason=0x55c9973b0e80 <sPrintfCrashReason> "mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction", aLine=440,
aFilename=0x7f2906ef2370 "/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h")
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:261
261 MOZ_REALLY_CRASH(aLine);
(gdb) list
256 MOZ_FUZZING_HANDLE_CRASH_EVENT4("MOZ_CRASH", aFilename, aLine, aReason);
257 #if defined(DEBUG) || defined(FUZZING)
258 MOZ_ReportCrash(aReason, aFilename, aLine);
259 #endif
260 MOZ_CRASH_ANNOTATE(aReason);
261 MOZ_REALLY_CRASH(aLine);
262 }
263 #define MOZ_CRASH_UNSAFE(reason) MOZ_Crash(__FILE__, __LINE__, reason)
264
265 static const size_t sPrintfMaxArgs = 4;
(gdb) list 200
^CQuit
(gdb) list
266 static const size_t sPrintfCrashReasonSize = 1024;
267
268 MFBT_API MOZ_COLD MOZ_NEVER_INLINE MOZ_FORMAT_PRINTF(1, 2) const
269 char* MOZ_CrashPrintf(const char* aFormat, ...);
270
271 /*
272 * MOZ_CRASH_UNSAFE_PRINTF(format, arg1 [, args]) can be used when more
273 * information is desired than a string literal can supply. The caller provides
274 * a printf-style format string, which must be a string literal and between
275 * 1 and 4 additional arguments. A regular MOZ_CRASH() is preferred wherever
(gdb) list 265
^CQuit
(gdb) print aLine
$1 = 440
(gdb)
$2 = 440
(gdb)
```
I am not even sure if this particular instance of TB was running within valgrind now. I believe it was. But TB seems to run a few processes now and then, if the particular TB instance is a child process of the original process, I was not running it since I forgot to pass the flag to trace the child processes to valgrind.
Anyway, I am keeping the crashed process debugged by gdb so that if anyone has a suggestion to where to look, I can watch it.
Or I may try to run this again with clean slate of affairs and make sure TB runs under valgrind.
Anyway, it looks there *IS* a piece of code not releasing the list structure properly.
Oh I forgot to mention that I am using locally created DEBUG build that is why I saw this
crash.
I don't believe I see such list not released message using mbox regularly.
(but maybe I should test TB in a similar manner when my message folder is mbox.)
The above is what I found in a very short testing.
Bug 1333342 Comment 27 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I tested with a locally created TB.
Not a great news. TB crashes at shutdown.
I created a working copy of TB from local updated M-C/C-C (with only minimal patches created locally so as not to disturb the TB operation).
So this may be even newer than Daily available on the web.
As I learned a couple of years back, I can specify the mbox/maildir selection when the new account is created.
(And if I specify maildir, TB needed to restart).
Well, I received about 180 messages from locally running daemons. (This was tested under local linux machine. Actually a linux image inside virtualbox.)
I repeated copying the repeated messages to a newly created empty directory.
After the message count exceeded 1000+, there was no problem.
I did something similar by copying this 1000+ messages at once to a different folder.
Again, no problem.
But please note that such repeated copying of 180+ messages may not trigger real world conditions since the message ID strings are repeated, the time/date sender/receiver information is repeated.
OK, I quit the running TB. Here, I did not see crash.
So I used the following short shell snippet to send myself a couple of thousand e-mails to see how this impacts TB.
```
$ for f in $(seq 1 2000)
> do
> echo "\ntest test" | mail -s "test subject $f" ishikawa
> done
```
Well actually "\ntest ..." is meaningless, it can be simply "test test".
Well, |mail| under Debian GNU/Linux prompts for "cc:" address when called interactively on the shell line, but it turns out,
it does not seem to ask so, if it is invoked as part of shell script (or rather the input is a piple).
So it sends 2000 e-mails to me and I thought I would obtain 2000 e-mails from that by running TB again.
So I ran TB and try receiving messages. Great, I thought.
Actually, since I setup TB for automatically receiving messages at startup (by default, I think and periodic, too),
soon after TB was invoked it began receiving e-mails.
But then strangely, I only found I received 980 new e-mails in TB in Inbox. (I only found messages up to "test subject 980")
Something went wrong and TB is no longer able to receive the further e-mails.
I was not sure what was happening.
So I tried to receive remaining e-mails from mail command invoked from the shell.
I got this message:
```
$mail
Cannot read mailbox /var/mail/ishikawa: Conflict with previous locker
```
and sure enough, there was "ishikawa.lock" file.
Who or rather which program has created this lock file. TB (?), most likely.
So thought I would finish TB and would try to see if the lock file would disappear.
Then I hit this crash at the program finish stage.
```
Hit MOZ_CRASH(mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction) at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:440
#01: ???[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so +0x616b5e9]
#02: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3ef67]
#03: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3f10a]
#04: __libc_start_main[/lib/x86_64-linux-gnu/libc.so.6 +0x277f4]
#05: _start[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird +0x162fa]
#06: ??? (???:???)
Program /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird (pid = 50352) received signal 11.
Stack:
#01: ???[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so +0x6604035]
#02: ???[/lib/x86_64-linux-gnu/libpthread.so.0 +0x13200]
#03: ???[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/libxul.so +0x616b5f3]
#04: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3ef67]
#05: ???[/lib/x86_64-linux-gnu/libc.so.6 +0x3f10a]
#06: __libc_start_main[/lib/x86_64-linux-gnu/libc.so.6 +0x277f4]
#07: _start[/NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird +0x162fa]
#08: ??? (???:???)
Sleeping for 300 seconds.
Type 'gdb /NEW-SSD/moz-obj-dir/objdir-tb3/dist/bin/thunderbird 50352' to attach your debugger to this thread.
```
Ouch, so there could be a memory structure (List in this case), which may not be properly cleared, etc.
In a memory tight system, this could be a problem. I have 16GB memory assigned to virtualbox on a 32GB real memory PC.
When I looked at the stack using gdb, this is what I got.:
```
(gdb) where
#0 0x00007f290ce30335 in __GI___clock_nanosleep
(clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:43
#1 0x00007f290ce353f3 in __GI___nanosleep
(req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50)
at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007f290ce3532a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#3 0x00007f2904a28af9 in common_crap_handler(int, void const*)
(signum=11, aFirstFramePC=0x7f2904a03035 <nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)+197>) at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:95
#4 0x00007f2904a28b1d in ah_crap_handler(int) (signum=<optimized out>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:103
#5 0x00007f2904a03035 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)
(signo=11, info=0x7ffe9c2191b0, context=0x7ffe9c219080)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/profile/nsProfileLock.cpp:183
#6 0x00007f290d174200 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#7 MOZ_Crash
(aReason=0x55c9973b0e80 <sPrintfCrashReason> "mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction", aLine=440, aFilename=0x7f2906ef2370 "/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h") at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:261
#8 mozilla::LinkedList<nsSHistory>::~LinkedList() (this=<optimized out>, __in_chrg=<optimized out>)
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:440
--Type <RET> for more, q to quit, c to continue without paging--
#9 mozilla::LinkedList<nsSHistory>::~LinkedList() (this=<optimized out>, __in_chrg=<optimized out>)
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:437
#10 0x00007f290cda9f67 in __run_exit_handlers
(status=0, listp=0x7f290cf28738 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=true, run_dtors=run_dtors@entry=true) at exit.c:108
#11 0x00007f290cdaa10a in __GI_exit (status=<optimized out>) at exit.c:139
#12 0x00007f290cd927f4 in __libc_start_main (main=
0x55c99730ae90 <main(int, char**, char**)>, argc=2, argv=0x7ffe9c2197a8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe9c219798) at ../csu/libc-start.c:366
#13 0x000055c99730b2fa in _start ()
(gdb) where
#0 0x00007f290ce30335 in __GI___clock_nanosleep
(clock_id=clock_id@entry=0, flags=flags@entry=0, req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50) at ../sysdeps/unix/sysv/linux/clock_nanosleep.c:43
#1 0x00007f290ce353f3 in __GI___nanosleep
(req=req@entry=0x7ffe9c218f50, rem=rem@entry=0x7ffe9c218f50)
at ../sysdeps/unix/sysv/linux/nanosleep.c:25
#2 0x00007f290ce3532a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
#3 0x00007f2904a28af9 in common_crap_handler(int, void const*)
(signum=11, aFirstFramePC=0x7f2904a03035 <nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)+197>) at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:95
#4 0x00007f2904a28b1d in ah_crap_handler(int) (signum=<optimized out>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:103
#5 0x00007f2904a03035 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)
(signo=11, info=0x7ffe9c2191b0, context=0x7ffe9c219080)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/profile/nsProfileLock.cpp:183
#6 0x00007f290d174200 in <signal handler called> () at /lib/x86_64-linux-gnu/libpthread.so.0
#7 MOZ_Crash
(aReason=0x55c9973b0e80 <sPrintfCrashReason> "mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction", aLine=440, aFilename=0x7f2906ef2370 "/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h") at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:261
#8 mozilla::LinkedList<nsSHistory>::~LinkedList() (this=<optimized out>, __in_chrg=<optimized out>)
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h:440
--Type <RET> for more, q to quit, c to continue without paging--q
Quit
(gdb) up
#1 0x00007f290ce353f3 in __GI___nanosleep (req=req@entry=0x7ffe9c218f50,
rem=rem@entry=0x7ffe9c218f50) at ../sysdeps/unix/sysv/linux/nanosleep.c:25
25 ../sysdeps/unix/sysv/linux/nanosleep.c: No such file or directory.
(gdb) up
#2 0x00007f290ce3532a in __sleep (seconds=0) at ../sysdeps/posix/sleep.c:55
55 ../sysdeps/posix/sleep.c: No such file or directory.
(gdb) up
#3 0x00007f2904a28af9 in common_crap_handler (signum=11,
aFirstFramePC=0x7f2904a03035 <nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*)+197>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:95
95 sleep(_gdb_sleep_duration);
(gdb) up
#4 0x00007f2904a28b1d in ah_crap_handler (signum=<optimized out>)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/xre/nsSigHandlers.cpp:103
103 common_crap_handler(signum, CallerPC());
(gdb) up
#5 0x00007f2904a03035 in nsProfileLock::FatalSignalHandler (signo=11, info=0x7ffe9c2191b0,
context=0x7ffe9c219080)
at /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/profile/nsProfileLock.cpp:183
183 oldact->sa_handler(signo);
(gdb) up
#6 <signal handler called>
(gdb) up
#7 MOZ_Crash (
aReason=0x55c9973b0e80 <sPrintfCrashReason> "mozilla::LinkedList<T>::~LinkedList() [with T = nsSHistory] has a buggy user: it should have removed all this list's elements before the list's destruction", aLine=440,
aFilename=0x7f2906ef2370 "/NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/LinkedList.h")
at /NEW-SSD/moz-obj-dir/objdir-tb3/dist/include/mozilla/Assertions.h:261
261 MOZ_REALLY_CRASH(aLine);
(gdb) list
256 MOZ_FUZZING_HANDLE_CRASH_EVENT4("MOZ_CRASH", aFilename, aLine, aReason);
257 #if defined(DEBUG) || defined(FUZZING)
258 MOZ_ReportCrash(aReason, aFilename, aLine);
259 #endif
260 MOZ_CRASH_ANNOTATE(aReason);
261 MOZ_REALLY_CRASH(aLine);
262 }
263 #define MOZ_CRASH_UNSAFE(reason) MOZ_Crash(__FILE__, __LINE__, reason)
264
265 static const size_t sPrintfMaxArgs = 4;
(gdb) list 200
^CQuit
(gdb) list
266 static const size_t sPrintfCrashReasonSize = 1024;
267
268 MFBT_API MOZ_COLD MOZ_NEVER_INLINE MOZ_FORMAT_PRINTF(1, 2) const
269 char* MOZ_CrashPrintf(const char* aFormat, ...);
270
271 /*
272 * MOZ_CRASH_UNSAFE_PRINTF(format, arg1 [, args]) can be used when more
273 * information is desired than a string literal can supply. The caller provides
274 * a printf-style format string, which must be a string literal and between
275 * 1 and 4 additional arguments. A regular MOZ_CRASH() is preferred wherever
(gdb) list 265
^CQuit
(gdb) print aLine
$1 = 440
(gdb)
$2 = 440
(gdb)
```
I am not even sure if this particular instance of TB was running within valgrind now. I believe it was. But TB seems to run a few processes now and then, if the particular TB instance is a child process of the original process, I was not running it since I forgot to pass the flag to trace the child processes to valgrind.
Anyway, I am keeping the crashed process debugged by gdb so that if anyone has a suggestion to where to look, I can watch it.
Or I may try to run this again with clean slate of affairs and make sure TB runs under valgrind.
Anyway, it looks there *IS* a piece of code not releasing the list structure properly.
Oh I forgot to mention that I am using locally created DEBUG build that is why I saw this
crash.
I don't believe I see such list not released message using mbox regularly.
(but maybe I should test TB in a similar manner when my message folder is mbox.)
The above is what I found in a very short testing.