Expected jit-test crash is incorrectly producing minidumps

RESOLVED FIXED in Firefox 60

Status

()

defect
P3
normal
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: sfink, Assigned: sfink, NeedInfo)

Tracking

unspecified
mozilla60
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox60 fixed)

Details

Attachments

(1 attachment)

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.
Priority: -- → P3
Summary: Expected jit-test crash is produces minidumps → Expected jit-test crash is incorrectly producing minidumps
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.
Attachment #8955301 - Flags: review?(jorendorff)
Assignee: nobody → sphink
Status: NEW → ASSIGNED
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!
Attachment #8955301 - Flags: review?(jorendorff) → review+
Pushed by sfink@mozilla.com:
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
https://hg.mozilla.org/mozilla-central/rev/4c72627cfc6c
Status: ASSIGNED → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla60
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 :)
Flags: needinfo?(sphink)
(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
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);
                                                                                   ^
(You can build with --enable-nspr-build to work around it, FWIW.)
Depends on: 1443147
You need to log in before you can comment on or make changes to this bug.