Bug 1333342 Comment 35 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Oh, one other thing. The crash under valgrind may be caused by the timing race.

There are places where the timing of events are not strictly controlled by the program flow.
Sometimes a group of events can occur in any order.
But sometimes a group of events have to occur in a certain sequence.
In those cases, programmers need to make sure to interlock the operation by certain synchronization primitives.
Problem is that some programmers have simply "assume" that some operations finish
before others because such was the case before.
Unfortunately, valgrind/memcheck skews the execution speed of program so much so that such "assumption" no longer holds.
So the error I see about referencing 0xc3c3c3...c3 to pick up an address to possibly a code that was to be executed at the termination
may have been caused by such mis-ordering due to the lack of proper sync. Just a theory, but very plausible.

I am saying because as soon as TB under valgrind starts (well I say "as soon as", but it is almost like 20-30 seconds before I see the following message after invocation. Valgrind/memcheck is sloooow.),
I see the following message.
```
==68965== Memcheck, a memory error detector
==68965== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==68965== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info
==68965== Command: /KERNEL-SRC/moz-obj-dir/objdir-tb3/dist/bin/thunderbird-bin -p
==68965==
==68965== Warning: set address range perms: large range [0x7a756a20000, 0x7a7d6620000) (noaccess)
[Parent 68965, Main Thread] WARNING: dependent window created without a parent: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/components/startup/nsAppStartup.cpp:744
==68965== Warning: set address range perms: large range [0x59c8a000, 0x459c8a000) (noaccess)
==68965== Warning: set address range perms: large range [0x59c8a000, 0x459c8a000) (noaccess)
[Parent 68965, Main Thread] WARNING: NS_ENSURE_TRUE(rootFrame) failed: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/base/nsGlobalWindowOuter.cpp:4235
[Parent 68965, Main Thread] WARNING: NS_ENSURE_TRUE(root) failed: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/base/nsDocumentViewer.cpp:2619
Warning: asking to enable_gpu_markers but no supporting extension was found

```
I suspect that main code of TB NEEDs to wait for a window or something to appear BEFORE proceeding, but 
under normal circumstances, the window gets ready before TB needs and so all is well. However, under valgrind, it may be too slow to create a required window or something. The message is very disturbing.
Oh, one other thing. The crash under valgrind may be caused by the timing race.

There are places where the timing of events are not strictly controlled by the program flow.
Sometimes a group of events can occur in any order.
But sometimes a group of events have to occur in a certain sequence.
In those cases, programmers need to make sure to interlock the operation by certain synchronization primitives.
Problem is that some programmers have simply "assume" that some operations finish
before others because such was the case before.
Unfortunately, valgrind/memcheck skews the execution speed of program so much so that such "assumption" no longer holds.
So the error I see about referencing 0xc3c3c3...c3 to pick up an address to possibly a code that was to be executed at the termination
may have been caused by such mis-ordering due to the lack of proper sync. Just a theory, but very plausible.

I am saying because as soon as TB under valgrind starts (well I say "as soon as", but it is almost like 20-30 seconds before I see the following message after invocation. Valgrind/memcheck is sloooow.),
I see the following message.
```
==68965== Memcheck, a memory error detector
==68965== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==68965== Using Valgrind-3.18.0.GIT and LibVEX; rerun with -h for copyright info
==68965== Command: /KERNEL-SRC/moz-obj-dir/objdir-tb3/dist/bin/thunderbird-bin -p
==68965==
==68965== Warning: set address range perms: large range [0x7a756a20000, 0x7a7d6620000) (noaccess)
[Parent 68965, Main Thread] WARNING: dependent window created without a parent: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/toolkit/components/startup/nsAppStartup.cpp:744
==68965== Warning: set address range perms: large range [0x59c8a000, 0x459c8a000) (noaccess)
==68965== Warning: set address range perms: large range [0x59c8a000, 0x459c8a000) (noaccess)
[Parent 68965, Main Thread] WARNING: NS_ENSURE_TRUE(rootFrame) failed: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/dom/base/nsGlobalWindowOuter.cpp:4235
[Parent 68965, Main Thread] WARNING: NS_ENSURE_TRUE(root) failed: file /NEW-SSD/NREF-COMM-CENTRAL/mozilla/layout/base/nsDocumentViewer.cpp:2619
Warning: asking to enable_gpu_markers but no supporting extension was found

```
I suspect that main code of TB NEEDs to wait for a window or something to appear BEFORE proceeding, but 
under normal circumstances, the window gets ready before TB needs and so all is well. However, under valgrind, it may be too slow to create a required window or something. The message is very disturbing. That TB works under this condition is a bit surprising.

Back to Bug 1333342 Comment 35