1441454 - Expected jit-test crash is incorrectly producing minidumps

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect, P3)

Description

[Steve Fink [:sfink] [:s:]]

The spidermonkey job log files appear to have PROCESS-CRASH stacks from self-test/assertRecoveredOnBailout-1.js, which is an expected crash.

This isn't supposed to happen. I ran it locally and verified that --suppress-minidumps is correctly passed to the JS shell in this case. I haven't looked farther than that yet.

Comment 1

[Steve Fink [:sfink] [:s:]]

Attachment: Dynamically load library with global linkage so that we can access symbols within them

The problem was that --suppress-minidump needs to toggle a boolean from the breakpad injector, but when using real NSPR, it was not getting loaded with RTLD_GLOBAL.

This should fix the |jit-test| crash problem; I haven't yet tracked down the bigger problem.

Comment 2

[Jason Orendorff [:jorendorff]]

Comment on attachment 8955301 [details] [diff] [review]
Dynamically load library with global linkage so that we can access symbols within them

Review of attachment 8955301 [details] [diff] [review]:
-----------------------------------------------------------------

Oh, I see, it's required for the later dlsym to work. Hmm. (thinks a bit) OK!

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/4c72627cfc6c
Dynamically load library with global linkage so that we can access symbols within them, r=jorendorff

Comment 4

[Cristian Brindusan [:cbrindusan]]

https://hg.mozilla.org/mozilla-central/rev/4c72627cfc6c

Comment 5

[Jan de Mooij [:jandem]]

I think this broke the (shell) build with Posix NSPR, at least on OS X I get errors about the compiler not knowing PRLibSpec, PR_LibSpec_Pathname, PR_LD_NOW, etc :)

Comment 6

[Paul Bone [:pbone]]

(In reply to Jan de Mooij [:jandem] from comment #5)
> I think this broke the (shell) build with Posix NSPR, at least on OS X I get
> errors about the compiler not knowing PRLibSpec, PR_LibSpec_Pathname,
> PR_LD_NOW, etc :)

Same on x86_64 Mint Linux with gcc 5.4.0

Comment 7

[Lars T Hansen [:lth]]

Same on OpenSUSE Linux with gcc 6 (ARM64).

/home/lhansen/m-i/js/src/shell/js.cpp: In member function ‘PRLibrary* AutoLibraryLoader::load(const char*)’:
/home/lhansen/m-i/js/src/shell/js.cpp:8893:9: error: ‘PRLibSpec’ was not declared in this scope
         PRLibSpec libSpec;
         ^~~~~~~~~
/home/lhansen/m-i/js/src/shell/js.cpp:8894:9: error: ‘libSpec’ was not declared in this scope
         libSpec.type = PR_LibSpec_Pathname;
         ^~~~~~~
/home/lhansen/m-i/js/src/shell/js.cpp:8894:24: error: ‘PR_LibSpec_Pathname’ was not declared in this scope
         libSpec.type = PR_LibSpec_Pathname;
                        ^~~~~~~~~~~~~~~~~~~
/home/lhansen/m-i/js/src/shell/js.cpp:8896:59: error: ‘PR_LD_NOW’ was not declared in this scope
         PRLibrary* dll = PR_LoadLibraryWithFlags(libSpec, PR_LD_NOW | PR_LD_GLOBAL);
                                                           ^~~~~~~~~
/home/lhansen/m-i/js/src/shell/js.cpp:8896:71: error: ‘PR_LD_GLOBAL’ was not declared in this scope
         PRLibrary* dll = PR_LoadLibraryWithFlags(libSpec, PR_LD_NOW | PR_LD_GLOBAL);
                                                                       ^~~~~~~~~~~~
/home/lhansen/m-i/js/src/shell/js.cpp:8896:83: error: ‘PR_LoadLibraryWithFlags’ was not declared in this scope
         PRLibrary* dll = PR_LoadLibraryWithFlags(libSpec, PR_LD_NOW | PR_LD_GLOBAL);
                                                                                   ^

Comment 8

[Jan de Mooij [:jandem]]

(You can build with --enable-nspr-build to work around it, FWIW.)