(In reply to Irvan Kurniawan (:sourc7) from comment #33) > Created attachment 9340705 [details] > testcase2.html > > (In reply to Camelia Badau [:cbadau], Desktop QA from comment #31) > > Noticed in Comment 27, that Manual QE is needed for verifying this. Can we use the STR from the Description and the attached "testcase1.html" for our verification? Or is there another testcase available that we should use? > > The current attached testcase1.html is using `new Worker` to help fill the memory, on latest Firefox it now hitting JS assertion and worker limit assertion. > > On new attached testcase2.html it's now using retry fill method and no longer using `new Worker` to fill the memory, however the success rate is not 100% to hit access-violation on SHA256, so we can use FFPuppet to automate retry the testcase2.html, when run 20x on my i5-1035G1 I able to get 9x success, 11x failure (about 45% success rate), on my other machine it only get 5x success, however I think it's enough for QE testing to prove the fix. > > ## Steps to reproduce: > 1. Run `pip install ffpuppet` in PowerShell > 2. Download attached testcase2.html > 3. Make new directory and enter the directory > 4. Type `for ($i = 1; $i -le 20; $i++) { python -m ffpuppet "[firefox path]" -u "[path to testcase file]" }` on PowerShell > 5. Change `[firefox path]` to Firefox 32-bit path i.e. `C:/Program Files (x86)/Firefox/firefox.exe` > 6. Change `[path to testcase file]` to testcase2.html path i.e. `C:/tmp/testcase2.html` > 7. Run the command > 8. After the command is completed, find "SHA256" text in the folder > 9. If "SHA256" text is found, then the Firefox build is affected Using the old Nightly build from 2023-06-03 (32bit), the testcase2.html and the steps provided here I can't seem to see SHA256 anywhere in the directory where the logs are created and nothing inside the logs as well. I tested on both Windows 11 on a VM and Windows 10 on a real machine. Any thoughts? Here is the content of a log file that has more info in it then the rest: `out of memory: 0x0000000000000188 bytes requested` `[ERROR viaduct::backend::ffi] Missing HTTP status` `[Parent 21040, IPC I/O Parent] WARNING: DuplicateHandle failed for handle 0 in TransferHandles: file /builds/worker/checkouts/gecko/ipc/chromium/src/chrome/common/ipc_channel_win.cc:787` `[ERROR viaduct::backend::ffi] Missing HTTP status` `[ERROR viaduct::backend::ffi] Missing HTTP status` `[ffpuppet] Reason code: ALERT` Note that I do see similar log files and directory names and all with the last Nightly from today as well.
Bug 1826002 Comment 34 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Irvan Kurniawan (:sourc7) from comment #33) > Created attachment 9340705 [details] > testcase2.html > > (In reply to Camelia Badau [:cbadau], Desktop QA from comment #31) > > Noticed in Comment 27, that Manual QE is needed for verifying this. Can we use the STR from the Description and the attached "testcase1.html" for our verification? Or is there another testcase available that we should use? > > The current attached testcase1.html is using `new Worker` to help fill the memory, on latest Firefox it now hitting JS assertion and worker limit assertion. > > On new attached testcase2.html it's now using retry fill method and no longer using `new Worker` to fill the memory, however the success rate is not 100% to hit access-violation on SHA256, so we can use FFPuppet to automate retry the testcase2.html, when run 20x on my i5-1035G1 I able to get 9x success, 11x failure (about 45% success rate), on my other machine it only get 5x success, however I think it's enough for QE testing to prove the fix. > > ## Steps to reproduce: > 1. Run `pip install ffpuppet` in PowerShell > 2. Download attached testcase2.html > 3. Make new directory and enter the directory > 4. Type `for ($i = 1; $i -le 20; $i++) { python -m ffpuppet "[firefox path]" -u "[path to testcase file]" }` on PowerShell > 5. Change `[firefox path]` to Firefox 32-bit path i.e. `C:/Program Files (x86)/Firefox/firefox.exe` > 6. Change `[path to testcase file]` to testcase2.html path i.e. `C:/tmp/testcase2.html` > 7. Run the command > 8. After the command is completed, find "SHA256" text in the folder > 9. If "SHA256" text is found, then the Firefox build is affected Using the old Nightly build from 2023-06-03 (32bit), the testcase2.html and the steps provided here I can't seem to see SHA256 anywhere in the directory where the logs are created and nothing inside the logs as well. I tested on both Windows 11 on a VM and Windows 10 on a real machine. Any thoughts? Here is the content of a log file that has more info in it then the rest: `out of memory: 0x0000000000000188 bytes requested` `[ERROR viaduct::backend::ffi] Missing HTTP status` `[Parent 21040, IPC I/O Parent] WARNING: DuplicateHandle failed for handle 0 in TransferHandles: file /builds/worker/checkouts/gecko/ipc/chromium/src/chrome/common/ipc_channel_win.cc:787` `[ERROR viaduct::backend::ffi] Missing HTTP status` `[ERROR viaduct::backend::ffi] Missing HTTP status` `[ffpuppet] Reason code: ALERT` Note that I do see similar log files and directory names and all with the last Nightly from today as well. Also I having an AMD Ryzen 7 2700x CPU on the machine not an intel as you said, not sure if this is relevant or not.