Closed Bug 1253491 Opened 4 years ago Closed 3 months ago
crash in ns
Purple Buffer::Block::Visit Entries<T>
This bug was filed from the Socorro interface and is report bp-a095de28-df32-4cbe-81a7-04a822160302. ============================================================= Case 1 Steps:- 1. Create a text file in notepad at path C:\moztest.txt 2. Enter content "Mary had a little lamp" 3. Save C:\moztest.txt and note the number of bytes 4. Switch to Firefox 5. Open attachment read_file_2.html 6. Click browse button 7. open file C:\moztest.txt 8. See the text loaded "Mary had a little lamp" 9. Switch to Notepad C:\moztest.txt 10. Change text "Mary" to "Jane" 11. Save C:\moztest.txt make sure byte count have not changed 12. Switch to Firefox 13. Click "Reload" button 14. See text changed to "Jane had a little lamp" 15. Switch to Notepad C:\moztest.txt 16. Change text "Jane" to "Joe" 17. Save C:\moztest.txt make sure byte count have not changed 18. Switch to Firefox 19. Click Reload button Expected * Text changed to "Joe had a little lamp" * file size & buffer.byteLength say actual on the disk Result 47.0a1 (2016-03-03) * Text still say "Jane had a little lamp" 44.0.2 * Text changes as expected to "Joe" * But file size still say 22 Case 2 Steps:- Prerequisite: Need "Notepad++" (https://notepad-plus-plus.org/ ) 1. Open attachment read_file_2.html 2. click browse button 3. Open C:\moztest.txt 4. See content displayed in the TEXTAREA 5. Open C:\moztest.txt in "Notepad++" 6. From menu "Encoding > Convert to Big Endian" 7. Save C:\moztest.txt 8. Note the byte count 9. Switch to Firefox Expected * Text displayed as original * file size & buffer.byteLength say actual on disk Result 47.0a1 (2016-03-03) * Text not changed * file size & buffer.byteLength not reflucting actual Byte count 44.0.2 * Textarea 1 Display text correctly * Textarea 2, text may get chopped off or extra byes are shown * file size & buffer.byteLength not reflucting actual Byte count * After few seconds Firefox crashes with signature that are different each time see https://crash-stats.mozilla.com/report/index/bp-a095de28-df32-4cbe-81a7-04a822160302 https://crash-stats.mozilla.com/report/index/bp-9c096373-e89e-4136-bad6-23e882160302 https://crash-stats.mozilla.com/report/index/bp-543e4dfa-f6e6-4aaf-90e1-b4c932160302 https://crash-stats.mozilla.com/report/index/bp-7189e18a-1ea8-48a8-a645-b26cb2160302 https://crash-stats.mozilla.com/report/index/bp-e144ac05-2677-47be-93ad-25fd22160302 https://crash-stats.mozilla.com/report/index/bp-0cac78f6-50cc-4146-8784-1859c2160302 https://crash-stats.mozilla.com/report/index/bp-aa0448ef-76f3-46d1-bfab-2b35d2160302 https://crash-stats.mozilla.com/report/index/bp-0cac78f6-50cc-4146-8784-1859c2160302 https://crash-stats.mozilla.com/report/index/bp-5438aefe-6155-4d51-92da-8a6e92160302 https://crash-stats.mozilla.com/report/index/7edf73d1-171a-49f5-9453-c14a92160301
Component: Tabbed Browser → DOM: Core & HTML
Product: Firefox → Core
So the crash-stats have very different stack traces. What is this bug about? The case 1's result talks about some text, case 2 about some byte length and some crashes. If this is about various different issues, please file separate bugs on them.
Status: NEW → UNCONFIRMED
Ever confirmed: false
(In reply to Olli Pettay [:smaug] from comment #2) > So the crash-stats have very different stack traces. What is this bug about? Correct. Every time when it crash we get different stack traces for this bug. > If this is about various different issues, please file separate bugs on them. I have split the regression part to bug 1260606
I get this crash every time I open an article at the AV Club, open a new tab, wait ~30s, then switch back to the AV Club tab. e.g. http://www.avclub.com/tvclub/sharon-and-rob-fight-mom-bies-and-hot-french-woman-235039
email@example.com, do you have crash reports for the issue? Could you perhaps copy-paste links to those? The original comment in this bug contained so many different and totally unrelated crash reports that it is a bit hard to know which crash you're seeing.
Here's the crash report: https://crash-stats.mozilla.com/report/index/7dc3d8c2-ad01-4ccb-940d-ace092160409 Having a look at crash reports, it seems that the same actions also triggered another crash, with the next day's Nightly build: (@ WaitForMultipleObjectsEx | MsgWaitForMultipleObjectsEx | mozilla::widget::WinUtils::WaitForMessage | nsAppShell::ProcessNextNativeEvent) https://crash-stats.mozilla.com/report/index/e0de2d75-6217-4a36-b8ba-89b352160409 https://crash-stats.mozilla.com/report/index/8b32c20f-de75-4107-8303-decbc2160410
Finally, I also have extensions.interposition.enabled set to false (does not show up in about:support).
Status: UNCONFIRMED → RESOLVED
Closed: 3 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.