crash on site http://rpg.mo.ee/ #212
Comments
|
Same happens here and the crash report shows about the same thing. What makes me suspicious is this: That looks like some "lazy commit" feature that only commits memory when it runs into an exception on using uncommited memory. Lars |
|
FF 45.5 on fresh ArcaOS 5.0 install. No crash until I moved the mouse. My trap is different however, referencing read/exec memory in FF and read/write memory in PMMERGE (same EDI, however). I am using SMOUSE with comet cursor, so perhaps that triggered a failure for a different reason. Video in this system is Panorama. |
|
On 05/26/17 11:01 PM, Lewis Rosenthal wrote:
I am using SMOUSE with comet cursor, so perhaps that triggered a failure
for a different reason.
Forget the specifics right now, but for quite a while using the comet
cursor resulted in crashes and was heavily discouraged.
|
|
Yeah, but I've never seen any of that. SM is rock solid 99% of the time, and I use comet cursor with animated pointers under accelerated SNAP all the time (I do have to disable full acceleration in the browser, however). In this test setup, I just disabled comet cursor, rebooted, and got exactly the same trap at the same time as the last one (as soon as I moved the mouse). |
|
Reference issue #215. It can load the whole page. The thing in a Google map is that if you move the mouse over the non map area of the page (list on the left with lines and markers) it doesn't crash. As soon as the mouse pointer enter the map area it crash. Something you may take into account to find the cause. |
|
I confirm this. With 45.9.0 addresses and line numbers are a bit different, but are essentially the same. Attaching a trap report just in case. |
|
Turned out to be a nasty typo when blindly merging ESR 45 that got triggered when changing the mouse cursor shape. Fixed (see above). Doesn't crash here any more. Please try this test build to see if it works for you: http://rpm.netlabs.org/test/yb9p2.zip. |
|
Thanks. Works now. At least for a few minutes. Old version crashed immediately on loading so pretty sure this is fixed. |
It just write to popuplog.os206-15-2017 21:15:12 SYS2070 PID 005c TID 0001 Slot 00a3
|
|
You need to update libcx. Yum update libcx. Then it will run. |
|
Hi, Jan-Erik... libcx 0.5.3 just landed in netlabs-rel. You need to update (likely you are running 0.5.2). I would also recommend updating libc while you're at it. That should get 45.9 working for you. |
|
Guys!
On Sun, 18 Jun 2017 13:28:36 -0700, Lewis Rosenthal wrote:
Hi, Jan-Erik...
libcx 0.5.3 just landed in netlabs-rel. You need to update (likely you are running 0.5.2). I would
also recommend updating libc while you're at it.
That should get 45.9 working for you.
For what it's worth, I just updated libcx to 0.5.3 (from netlabs-rel), following a full system
re-boot with this latest FF drop (45.9.x) I am now getting the following in my popuplog.os2:
…------------------------------------------------------------
06-18-2017 19:51:38 SYS2070 PID 0078 TID 0001 Slot 00a6
G:\APPS\TCPIP\FIREFOX_45\FIREFOX.EXE
XUL->LIBCX0._fread
127
------------------------------------------------------------
I will go back to the prior 45.5.x release to see if the behaviour is the same.
Thanks,
-Dariusz
|
|
On Sun, 18 Jun 2017 19:55:51 -0400 (EDT), Dariusz Piatkowski wrote:
Guys!
For what it's worth, I just updated libcx to 0.5.3 (from netlabs-rel), following a full system
re-boot with this latest FF drop (45.9.x) I am now getting the following in my popuplog.os2:
------------------------------------------------------------
06-18-2017 19:51:38 SYS2070 PID 0078 TID 0001 Slot 00a6
G:\APPS\TCPIP\FIREFOX_45\FIREFOX.EXE
XUL->LIBCX0._fread
127
------------------------------------------------------------
I will go back to the prior 45.5.x release to see if the behaviour is the same.
Thanks,
-Dariusz
OK, so report out on the move back to 45.5.x release, it works fine with the latest libcx 0.5.3
release...so at least I am seeing the same popuplog.os2 entry as JanErikLaerka.
Now here is what else I noticed, not sure if this has any bearing on the error, but the test drop
of FF (yb9p2.zip) seems to have a weird looking directory structure, here is what I mean:
FF 45.5.x
=======
Directory of G:\apps\tcpip\firefox_45
6-18-17 8:01p <DIR> 0 .
6-18-17 8:01p <DIR> 0 ..
5-16-17 2:29p 419 124 application.ini
6-18-17 8:01p <DIR> 124 browser
5-19-17 4:28p 4321 124 CHANGES.OS2
6-18-17 8:01p <DIR> 124 defaults
5-16-17 3:50p 9 124 dependentlibs.list
6-18-17 8:01p <DIR> 124 dictionaries
5-19-17 5:40p 64886 124 firefox.exe
6-18-17 8:01p <DIR> 124 gmp-clearkey
5-19-17 5:40p 68058 124 lgpllibs.dll
5-15-17 8:44p 10527 124 MozSounds.cmd
5-19-17 5:40p 529184 124 mozsqlt3.dll
5-16-17 4:00p 9644797 124 omni.ja
5-16-17 3:58p 51 124 platform.ini
5-19-17 4:30p 29046 124 README.OS2
5-19-17 5:40p 38430177 124 xul.dll
17 file(s) 48781475 bytes used
FF 45.9.x
=======
Directory of G:\apps\tcpip\firefox_45_9
6-18-17 7:57p <DIR> 0 .
6-18-17 8:01p <DIR> 0 ..
12-09-16 1:42p 5031 124 .gdbinit
5-31-17 4:26p 145 124 .lldbinit
5-31-17 4:15p 436 124 application.ini
6-18-17 7:57p <DIR> 124 browser
5-19-17 5:44p 4544 124 CHANGES.OS2
6-18-17 7:57p <DIR> 124 chrome
6-14-17 2:40p 3966 124 chrome.manifest
6-18-17 7:57p <DIR> 124 components
6-18-17 7:57p <DIR> 124 defaults
6-14-17 3:47p 9 124 dependentlibs.list
6-18-17 7:57p <DIR> 124 dictionaries
6-14-17 12:25p 450388 124 firefox.exe
6-18-17 7:57p <DIR> 124 gmp-clearkey
6-18-17 7:57p <DIR> 124 gmp-fake
6-18-17 7:57p <DIR> 124 gmp-fakeopenh264
5-31-17 4:27p 165997 124 greprefs.js
6-18-17 7:57p <DIR> 124 hyphenation
5-31-17 4:03p 267 124 js-gdb.py
5-31-17 4:02p 57518836 124 js.exe
5-31-17 3:12p 441873 124 lgpllibs.dll
6-18-17 7:57p <DIR> 124 modules
12-09-16 2:44p 10527 124 MozSounds.cmd
5-31-17 3:12p 1904171 124 mozsqlt3.dll
5-31-17 1:59p 13333 124 nsinstall.exe
5-31-17 4:30p 51 124 platform.ini
5-31-17 4:24p 303896 124 plugin-container.exe
5-19-17 4:30p 29046 124 README.OS2
6-18-17 7:57p <DIR> 124 res
5-31-17 4:29p 7 124 update.locale
5-31-17 4:24p 290305 124 xpcshell.exe
6-14-17 3:47p 453227993 124 xul.dll
33 file(s) 514370821 bytes used
Not sure if this was to be expected (maybe part of debug build???) or whether the 45.5 vs
45.9 is a singificantly different structure that brings all these extra directories in???
Thanks,
-Dariusz
|
|
On 06/18/17 05:36 PM, Dariusz Piatkowski wrote:
Not sure if this was to be expected (maybe part of debug build???)
The 45.9.0 is just the regular results of running make package. 45.5
looks like all the stuff that is not useful has been removed.
|
|
@dspiatkowski you surely don't have LIBCx 0.5.3 on LIBPATH when running FF 45.9. Fix your environment and it will work. |
|
Hi Dimitriy!
On Mon, 19 Jun 2017 03:47:03 -0700, Dmitriy Kuminov wrote:
@dspiatkowski you surely don't have LIBCx 0.5.3 on LIBPATH when running FF 45.9. Fix your
environment and it will work.
I don't know what to tell you (tossing my hands up in sheer desparation...LOL). This RPM/YUM
thing is becoming more a bear than the saviour I thought it would be.
Look, all I can say is that I did the following:
1) used ANPM to install the latest release (0.5.3)
- install went fine, no complaints, the updated (judging by date/time stamp since no BLDLEVEL
info is available) was placed in my \usr\lib directory, which is the standard RPM/YUM install
base
- 'yum list' reports the following for libcx
libcx.i686 0.5.3-1.oc00 installed
2) I made sure that this DLL in \usr\lib was the ONLY such DLL on my system, indeed, it is the
only one and that LIBPATH was set accordingly:
LIBPATH=.;g:\usr\local\lib;G:\usr\lib;g:\usr\dll;G:\;G:\OS2;G:\OS2\DLL;...
3) I re-booted my machine to make sure that anything previously loaded into memory would
NOT impact FF 45_9
4) I ran the 45_9 release, seeing the same issue that the op reported I confirmed that
behaviour on my system
Again, I reported what I found, that's all.
Anyways, the DLL loading issue, whatever it may be must be related to some other stuff,
especialy if others have been able to do this successfully.
If anything in the above steps is done incorrectly I would want to know in order to avoid this
re-occurence in the future. If it all looks good then please move along to the more important
stuff and I'll deal with the DLL updates by manually verifying and re-verifying, etc, etc..
…-Dariusz
|
|
Dariusz, please install PMDLL, and check xul.dll to see if there is something else not loading properly. What I see with an outdated libcx, for example, is that lgpllibs.dll will not load properly when called from xul.dll. Also, I am starting firefox.exe directly (no script, from a prompt in the program directory. All tests are done on ArcaOS 5.0 (now 5.0.1 test). |
|
Ok sry, done
2017-06-19 20:47 GMT+02:00 Lewis Rosenthal <notifications@github.com>:
… Please check existing tickets and open a fresh one if none exists which
address your issue. This ticket is specifically related to behavior of this
*one* site or others like it, and how to test.
Thanks
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#212 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AcLlSlieqOdmetQOSUsjxdrnw4IcERHgks5sFsI0gaJpZM4NmsJT>
.
|
|
@dspiatkowski Dariusz, from what you write it sounds like you have a correct environment. But |
Most times FF45 crashes immediately when going to that page. Sometimes it start loading data for a while before it crashes. SM2.35 does not crash. TRP follows -
The text was updated successfully, but these errors were encountered: