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