Bug 1991491 Comment 18 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Original comment by
on 
(In reply to Alex Franchuk [:afranchuk] from comment #12)
> So, interestingly, I couldn't reproduce the "Couldn't load XPCOM" dialog coming up when I followed your STR.

For completeness, my understanding is that reproducing the "Couldn't load XPCOM" requires crashing *during* DLL loading, so you need to repro `[@ google::protobuf::EncodedDescriptorDatabase::Add ]` (the 144 and 145 variation of bug 1816848) and not `[@ mozilla::LinkedListElement<T>::setPreviousUnsafe ]` (the 143- variation of bug 1816848), which was crashing *after* DLL loading. The DLL shared in comment 0 will repro the latter. In order to reproduce the former you need to corrupt the xul.dll from a 144 or 145 build using the Python script from comment 0 and used that corrupted file rather than the DLL I shared. Sorry if that wasn't clear.
Revision 1 by
on 
(In reply to Alex Franchuk [:afranchuk] from comment #12)
> So, interestingly, I couldn't reproduce the "Couldn't load XPCOM" dialog coming up when I followed your STR.

For completeness, my understanding is that reproducing the "Couldn't load XPCOM" requires crashing *during* DLL loading, so you need to repro `[@ google::protobuf::EncodedDescriptorDatabase::Add ]` (the 144 and 145 variation of bug 1816848) and not `[@ mozilla::LinkedListElement<T>::setPreviousUnsafe ]` (the 143- variation of bug 1816848), which was crashing *after* DLL loading. The DLL shared in comment 0 will repro the latter. In order to reproduce the former you need to corrupt the xul.dll from a 144 or 145 build using the Python script from comment 0 and used that corrupted file rather than the DLL I shared. Sorry if "corrupting the new xul.dll" in comment 6 wasn't clear.
Revision 2 by
on 
(In reply to Alex Franchuk [:afranchuk] from comment #12)
> So, interestingly, I couldn't reproduce the "Couldn't load XPCOM" dialog coming up when I followed your STR.

For completeness, my understanding is that reproducing the "Couldn't load XPCOM" requires crashing *during* DLL loading, so you need to repro `[@ google::protobuf::EncodedDescriptorDatabase::Add ]` (the 144 and 145 variation of bug 1816848) and not `[@ mozilla::LinkedListElement<T>::setPreviousUnsafe ]` (the 143- variation of bug 1816848), which was crashing *after* DLL loading. The DLL shared in comment 0 will repro the latter. In order to reproduce the former you need to corrupt the xul.dll from a 144 or 145 build using the Python script from comment 0 and used that corrupted file rather than the DLL I shared. Sorry if "corrupting the new xul.dll" in comment 11 wasn't clear.
Revision 3 by
on 
(In reply to Alex Franchuk [:afranchuk] from comment #12)
> So, interestingly, I couldn't reproduce the "Couldn't load XPCOM" dialog coming up when I followed your STR.

For completeness, my understanding is that reproducing the "Couldn't load XPCOM" requires crashing *during* DLL loading, so you need to repro `[@ google::protobuf::EncodedDescriptorDatabase::Add ]` (the 144 and 145 variation of bug 1816848) and not `[@ mozilla::LinkedListElement<T>::setPreviousUnsafe ]` (the 143- variation of bug 1816848), which was crashing *after* DLL loading. The DLL shared in comment 0 will repro the latter. In order to reproduce the former you need to corrupt the xul.dll from a 144 or 145 build using the Python script from comment 0 and use that corrupted file rather than the DLL I shared. Sorry if "corrupting the new xul.dll" in comment 11 wasn't clear.

Back to Bug 1991491 Comment 18