Bugzilla

Great discovery. 
After so many months (actually a few years) of not being able to run thunderbird under valgrind as an ordinary user (under Debian GNU/Linux),
I could today.
To be exact, the versions are as follows.
```
ishikawa@ip030:/home/ishikawa$ uname -a
Linux ip030 5.10.0-4-amd64 #1 SMP Debian 5.10.19-1 (2021-03-02) x86_64 GNU/Linux
ishikawa@ip030:/home/ishikawa$ valgrind --version
valgrind-3.16.1
ishikawa@ip030:/home/ishikawa$ 
```
I even suspected a bug of virtualbox where my linux instance runs before.
virtualbox version is 6.1.18.

For the last few years up until several months ago, valgrind + TB combination produces mysterious segmentation fault of valgrind itself.
Small binary would run without an issue. But a large TB binary didn't . :-(

So being able to run valgrind and TB combination as an ordinary user opens up a much easier venue of debugging.
(I didn't want to do messy things as superuser under linux.)

I can possibly run builtin debugger vgdb of valgrind and place a breakpoint on clonse() system call that is used to create a  new thread and
see where all those more than 1500 threads are created. Possibly.
I have yet to figure out how to automate the "breakpoint reached. Create a stack dump. Continue" loop for more than 1500 threads creation.

If anyone has an idea on this, please let me know. 
It seems there is a builtin support for ruby script or something, but I am not sure.
I have not programmed gdb command files for quite sometime now.

Great discovery. 
After so many months (actually a few years) of not being able to run thunderbird under valgrind as an ordinary user (under Debian GNU/Linux),
I could today.
To be exact, the versions are as follows.
```
ishikawa@ip030:/home/ishikawa$ uname -a
Linux ip030 5.10.0-4-amd64 #1 SMP Debian 5.10.19-1 (2021-03-02) x86_64 GNU/Linux
ishikawa@ip030:/home/ishikawa$ valgrind --version
valgrind-3.16.1
ishikawa@ip030:/home/ishikawa$ 
```
I even suspected a bug of virtualbox where my linux instance runs before.
virtualbox version is 6.1.18.

For the last few years up until several months ago, valgrind + TB combination produces mysterious segmentation fault of valgrind itself.
Small binary would run without an issue. But a large TB binary didn't . :-(

So being able to run valgrind and TB combination as an ordinary user opens up a much easier venue of debugging.
(I didn't want to do messy things as superuser under linux.)

I can possibly run builtin debugger vgdb of valgrind and place a breakpoint on clone() system call that is used to create a  new thread and
see where all those more than 1500 threads are created. Possibly.
I have yet to figure out how to automate the "breakpoint reached. Create a stack dump. Continue" loop for more than 1500 threads creation.

If anyone has an idea on this, please let me know. 
It seems there is a builtin support for ruby script or something, but I am not sure.
I have not programmed gdb command files for quite sometime now.