Closed Bug 753340 Opened 14 years ago Closed 14 years ago

Create Mozmill Crash test for CheckASLR topcrash (bug 749648)

Categories

(Mozilla QA Graveyard :: Mozmill Tests, defect)

Product:
Mozilla QA Graveyard
Component:
Mozmill Tests
Platform:
All
Windows 7
Type:
defect
Priority:
Not set
Severity:
major

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: whimboo, Assigned: whimboo)

References

Details

There was a startup crash of Firefox with an add-on involved. See bug 749648 for all the details. Given that we do not have any test for it, we should get a Mozmill test implemented. I propose the following steps: 1. Reduce the add-on to make it a good testcase. Kyle, do you know if we can trust that add-on? Especially the DLL included? I'm kinda worried to open any security hole on the testing machines. 2. Create the appropriate Mozmill tests as a restart test 3. Create the crash testrun (should be filed as a separate bug)
I have no idea if the addon is safe. I never got a copy of it. The easiest way to test this would be to try to load a DLL that has no NT headers.
The copy of the add-on is attached to the implementaion bug 749648. (In reply to Kyle Huey [:khuey] (khuey@mozilla.com) from comment #1) > The easiest way to test this would be to try to load a DLL that has no NT headers. Sorry, but do you have some more information? I'm not familiar with DLLs at all and I would kindly appreciate details how to create such a DLL or even if you could provide one. Thanks a lot!
Even if I did provide one, we'd have to recompile it every six weeks. I'm not convinced it's worth the effort.
Can you explain why we would have to do it?
Because all binary components have to be recompiled for every release of Firefox.
Why would all binary components have to be recompiled for each release of Firefox? Binary components had to be recompiled to support ASLR but I have never heard that this would be required for each release of Firefox. How should extension authors handle that? That wouldn't be doable. Just for reference, our Nightly Tester tools has some DLL's and those work fine across all versions of Firefox. So I'm a bit puzzled now.
We've been doing this since rapid release started ...
Also the DLLs in NTT aren't XPCOM components (I assume they're used via ctypes or something).
Hmm, can't we just have an automated test for this? It's not clear to me why we need Mozmill here.
So the important link which explains the recompilation of XPCOM binaries here is: https://developer.mozilla.org/En/Developer_Guide/Interface_Compatibility#Binary_Interfaces Kyle, would be good to know if this really can't be done with our other existing test frameworks.
Given that we would have to recompile the XPCOM DLL for each version of Firefox on our own it doesn't make much sense to have a Mozmill test. Kyle pointed me to bug 728429 where he has written a test for ASLR and an XPCOM DLL. We could easily add a new one for this particular crash once we know what's wrong with this add-on DLL. I will try to get more details over on bug 749648 from Virgil. Closing this bug because it's better handled by XPCShell dependent on if we can find out the cause.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Product: Mozilla QA → Mozilla QA Graveyard
You need to log in before you can comment on or make changes to this bug.