MacPorts vs. Apple compiler issues, Handle

[Riccardo Mottola]

Hi,

Joshua Root wrote:
> (Moving to macports-dev as it is a better fit for this topic.)

indeed, it is a development issue, although well, not for a MacPorts 
package (yet?) but use of MP development tools.
>
> Issues that only appear at higher optimisation levels also often 
> involve undefined behaviour.
>

Right.. I reduced optimization to O1 with no change, I have strange 
issues compiling with O0!


>> Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
>> 0   XUL                               0x000000010f5468e1 
>> nsWindowWatcher::OpenWindowInternal(mozIDOMWindowProxy*, char const*, 
>> char const*, char const*, bool, bool, bool, nsITabParent*, nsIArray*, 
>> nsIDocShellLoadInfo*, mozIDOMWindowProxy**) + 273
>
> And this is where it happened. Since this is not a full debug build, 
> there is no line number information, but you at least know which 
> method is doing the bad memory access.
>

But it should be a debug build. Well a build with debug symbols (not a 
firefox-style debug which adds also a lot of debug code).
I add:
ac_add_options --disable-strip

and this helps on Linux usually.

Still, the nsWindowWatcher class gave me a clue and I found a couple of 
Firefox patches to import which initialized parameters, checked them, 
etc.... and now the error changed to>

0   XUL                               0x00000001035f5c44 
JS::Rooted<JSObject*>::registerWithRootLists(js::RootLists&) + 20
1   ???                               0x00007ffeecb477f0 0 + 140732869670896

this is bad, since it is inside the JS engine. Also the JS engine works 
on other system when compiled with modern clang and gcc!

Also here I don't have a class name which maps directly to a file which 
I can easily inspect.

I will try clang 7 & 8, just so.

Riccardo