Author Topic: Firefox and Traps  (Read 54821 times)

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: Firefox and Traps
« Reply #30 on: April 11, 2018, 02:28:37 am »
It's weird. What video driver and video card and video settings are you using?

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Firefox and Traps
« Reply #31 on: April 11, 2018, 03:21:41 am »
Hi Ben

Possibly a silly question: Have you tried dropping dive.dll onto PMdll to see if all files dive.dll uses load OK?


Regards

Pete

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: Firefox and Traps
« Reply #32 on: April 11, 2018, 08:08:07 am »
Ben, also you should use safe mode for testing. Firefox.exe -safe-mode and let it disable everything that it offers to do.

Ben

  • Guest
Re: Firefox and Traps
« Reply #33 on: April 11, 2018, 02:20:59 pm »
It's weird. What video driver and video card and video settings are you using?

I am using an ATI Radeon X300 series video card with the version of SNAP that came with eCS, (build 505).

Keep in mind that everything worked fine up until a month ago. I was experiencing serious hard disk trouble that I eventually diagnosed as serial bus timing issues, (due to the age of the MB).

A likely candidate as any is a corrupt file somewhere, but finding it, (should that actually be the problem), is another thing. When everything else on this OS install works well, (now), it's very hard to find exactly what is going on and I have a long list of running processes, (being my server machine); Apache/2, Hybrid IRCd, SQUID, mySQL, Privoxy, FTPd, IJFW, Changi NNTPd, Syslogd, Named and lesser servers.

Of course, I did close out everything on my machine leaving only the bare desktop, and tried Firefox, (all versions of), with the same results as I listed previously. Very odd; in all my years running OS/2, this is the only time I have ever seen anything like this that crosses all versions of Mozilla, yet leaves everything else untouched.

If it makes a difference the QT browsers do work, but they have little functionality.


On a nonrelated point that may be of interest to you, I am typing this message using the latest version of SeaMonkey, (on a different machine), and it works flawlessly so far.

Ben

  • Guest
Re: Firefox and Traps
« Reply #34 on: April 11, 2018, 02:23:44 pm »
Hi Ben
Possibly a silly question: Have you tried dropping dive.dll onto PMdll to see if all files dive.dll uses load OK?

Hi, again Pete.

I did try that using PMDLL ver 2.11, (AFAIK that's the latest version though I did not check), and everything seems to be loading OK.

Ben

  • Guest
Re: Firefox and Traps
« Reply #35 on: April 11, 2018, 02:27:26 pm »
Ben, also you should use safe mode for testing. Firefox.exe -safe-mode and let it disable everything that it offers to do.

I tried that and it loads and runs in safe mode through preliminary testing; I allowed it to disable all as requested.

Interesting given that I renamed the profile directory, (more than once), and doing so changed nothing ergo; it cannot be my profile(s).

So, the obvious question is; what now?

Andi B.

  • Hero Member
  • *****
  • Posts: 812
  • Karma: +11/-2
    • View Profile
Re: Firefox and Traps
« Reply #36 on: April 11, 2018, 02:52:11 pm »
I think you did not show your LIBPATH in this thread nor said if you tried the .; after the unixroot directories. It does not matter if ANPM put it to the front. You can overwrite this or instruct ANPM to not change the correct setting (= after the unixroot dirs or at the end). IMHO putting .; in front of unixroot dirs was the wrong decision. The discussion about is in AN bugtracker. You never know if the 'right' dlls (for FF) are loaded if you do not set you LIBPATH correct (= unixroot dirs in front) in config.sys.

The other thing is if you want different Mozilla builds (FF, SM, Thunderbird, ...) running in parallel you HAVE to use LIBPATHSTRICT/BEGINLIBPATH. Simplest way is with RUN. Even if you close one application it's a good idea to check if it is really closed f.i. with TOP.

If I got it right you could not manage to run even one application (FF) immediately after boot. Most probably reason for such behavior is wrong or missing dlls. Newest SM/FF needs dlls from exp repositories I think.

Ben

  • Guest
Re: Firefox and Traps
« Reply #37 on: April 11, 2018, 03:28:17 pm »
The following are my path statements:

Code: [Select]
REM *-------------------------------|| LIBPATH, PATH & DPATH STATEMENTS ||--------------------------------------*
LIBPATH=.;G:\usr\local\lib;G:\usr\lib;G:\ETC\DLL;C:\OS2\DLL;C:\IBMLAN\NETLIB;C:\MUGLIB\DLL;C:\MPTN\DLL;F:\4OS2;F:\CLU\DLL;C:\ECS\SYSTEM\SESS\DLL;C:\IBMCOM\DLL;C:\OS2\DLL\USER;C:\MMOS2\DLL;C:\PROGRAMS\OPENJDK6\BIN;C:\IBMGSK50\LIB;C:\IBMGSK40\LIB;C:\IBMGSK\LIB;C:\TCPIP\DLL;G:\SERVERS\CHANGI;C:\OS2\MDOS;C:\;C:\OS2\APPS\DLL;C:\EMX\DLL;C:\ECS\SYSTEM\AMOUSE;C:\OBJDESK;F:\PC\DLL;G:\USR\X11R6\LIB;G:\PERL\LIB;G:\PERL\BIN;C:\PROGRAMS\OPENSSH;F:\DISK\NETDRIVE;
SET PATH=G:\usr\local\bin;G:\usr\sbin;G:\usr\bin;F:\4OS2;F:\CLU\BIN;G:\USR\SBIN;G:\USR\BIN;C:\MPTN\BIN;C:\ECS\SYSTEM\SESS\BIN;C:\IBMCOM;C:\IBMLAN\NETPROG;G:\SERVERS\CHANGI;C:\MUGLIB;C:\ECS\BIN;C:\IBMGSK50\BIN;C:\IBMGSK40\BIN;C:\IBMGSK\BIN;C:\TCPIP\BIN;C:\OS2;C:\MMOS2;C:\PROGRAMS\OPENJDK6\BIN;C:\OS2\DLL\USER;C:\OS2\SYSTEM;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL;C:\;C:\OS2\MDOS;C:\OS2\APPS;C:\EMX\BIN;F:\PC\BIN;F:\MANAGERS\FM2;F:\MANAGERS\FM2\UTILS;F:\DISK\DFSEE\BIN;C:\OBJDESK;C:\OBJDESK\EXTRAS\BIN;F:\EDITORS\TSE;G:\PERL\BIN;C:\PROGRAMS\OPENSSH;F:\DISK\NETDRIVE;
SET DPATH=G:\usr\share\os2\lang;C:\MPTN;C:\IBMCOM;C:\IBMLAN\NETPROG;C:\IBMLAN;C:\MUGLIB;C:\ECS\LANG;C:\OS2;C:\OS2\SYSTEM;G:\SERVERS\CHANGI;F:\4OS2;F:\CLU\DATA;C:\OS2\MDOS\WINOS2;C:\OS2\INSTALL;C:\;C:\OS2\BITMAP;C:\OS2\MDOS;C:\OS2\APPS;C:\MMOS2;C:\MMOS2\INSTALL;F:\PC\LANGUAGE;C:\OBJDESK;G:\PERL\BIN;

I will try moving the ".;" after the unixroot dirs and see what happens.

Time passes...

OK.
I did try it and it made some difference.

Now, the profile window comes up and I click on it but, nothing else happens. Firefox neither loads nor hangs and no trap file is generated. Also, my mouse pointer no longer disappears after the second attempt at running.


WRT running different copies of Firefox and using the "RUN!" utility, some of the copies of Firefox that I have tested have that as the default setup.
I only use one copy of Firefox under normal circumstances; that is the latest edition that I have installed.
« Last Edit: April 11, 2018, 03:54:19 pm by Ben »

Andi B.

  • Hero Member
  • *****
  • Posts: 812
  • Karma: +11/-2
    • View Profile
Re: Firefox and Traps
« Reply #38 on: April 11, 2018, 03:52:10 pm »
....
OK.
I did try it and it made some difference.

Which proved you have old dlls on your system. Anyway no big problem for FF if you set the .; correct. Now the second obvious question - do you have all needed dlls for your FF version? To be more precise did you enable netlabs exp repository or do you use an older FF version which does not need the exp dlls?

Ben

  • Guest
Re: Firefox and Traps
« Reply #39 on: April 11, 2018, 03:57:56 pm »
For my guide on dlls, I used the RPM Requirements file that came with firefox-45.9.0-2.oc00.pentium4.7z.

If I have duplicate dlls on my system they are well hidden; is there a program that can search for duplicate DLLs? Whichdll only tells you which dll is loaded as the name declares.

Also, none of the older version of Firefox will run... same as prior to the libpath adjustment, but without the trap occurring etc.
« Last Edit: April 11, 2018, 04:06:32 pm by Ben »

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: Firefox and Traps
« Reply #40 on: April 11, 2018, 04:34:46 pm »
@Ben, if you look at the end of one of your trp files, you'll see a list of all DLLs loaded by Firefox/SeaMonkey. To me it looks correct except I've noticed that you have at least 3 different copies of exceptq.dll with your latest trp created by the copy installed with weasel.
I guess you have weasel loading in your startup folder or such. Be aware that if a program uses BEGINLIBPATH tp load a DLL, it'll be accessible by all programs no matter what your LIBPATH says. Perhaps try to disable everything in your startup folder.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: Firefox and Traps
« Reply #41 on: April 11, 2018, 04:54:15 pm »
Hi Ben

Yes, there is a tool to help spot duplicate files amongst other useful things: BS-Info available here http://www.wdsibyl.org/index.php?module=Downloads&func=display&lid=105&lang=en

It may take a few seconds to perform all of its checks when starting but when ready find the "Duplicate files" tab and give it a try. Note it can only check 1 drive at a time though.


Regards

Pete

Ben

  • Guest
Re: Firefox and Traps
« Reply #42 on: April 11, 2018, 09:41:28 pm »
@Ben, if you look at the end of one of your trp files, you'll see a list of all DLLs loaded by Firefox/SeaMonkey. To me it looks correct except I've noticed that you have at least 3 different copies of exceptq.dll with your latest trp created by the copy installed with weasel.
I guess you have weasel loading in your startup folder or such. Be aware that if a program uses BEGINLIBPATH tp load a DLL, it'll be accessible by all programs no matter what your LIBPATH says. Perhaps try to disable everything in your startup folder.

I do not have "BEGINLIBPATH" in the Weasel startup.cmd but I do use "'set path=G:\Servers\SMTP\Weasel;%PATH%'".

My guess is that that statement would do something similar though; is that correct?

I will stop all the servers again and give Firefox a try with todays adjustments in place.

Time passes...

OK. I did that, stopping all servers and it went back to the previous behaviour with the profile manager window disappearing after selecting a profile and taking my mouse pointer with it on the second attempt, but not generating a trap log.

Strange and confounding.

However,  it does appear as if something in one of my startup-server.cmds is having an affect on things for when I restarted them after the above test, the Firefox profile manager window once more exits cleanly and my mouse pointer no longer disappears. What a mess.

An interesting note, on my other machine when I moved the ".;" in my libpath to follow the unixroot paths, Firefox stopped working yielding a popup window that said XUL.DLL could not be loaded.
Firefox once again ran when I moved it back to the beginning of the statement. So, the debate on where that should go has not yet been solved.
« Last Edit: April 11, 2018, 10:28:17 pm by Ben »

Ben

  • Guest
Re: Firefox and Traps
« Reply #43 on: April 11, 2018, 09:46:35 pm »
Hi Ben

Yes, there is a tool to help spot duplicate files amongst other useful things: BS-Info available here http://www.wdsibyl.org/index.php?module=Downloads&func=display&lid=105&lang=en

It may take a few seconds to perform all of its checks when starting but when ready find the "Duplicate files" tab and give it a try. Note it can only check 1 drive at a time though.


Thanks for the headsup, Pete. I had a really old version of BS-Info that would not longer run. Unfortunately, the newer version starts up but hangs after about 5 seconds while displaying the clock. It just sits there consuming one of the cores. It is easily killable, but not presently useable on the server machine.

It works great on my other machine and it has surely found quite a number of duplicate DLLs. Wow...
Too bad it only checks one drive at a time, but it does make the job easier.

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4788
  • Karma: +99/-1
    • View Profile
Re: Firefox and Traps
« Reply #44 on: April 11, 2018, 11:11:52 pm »

I do not have "BEGINLIBPATH" in the Weasel startup.cmd but I do use "'set path=G:\Servers\SMTP\Weasel;%PATH%'".

My guess is that that statement would do something similar though; is that correct?

Yes, the binary would use the dot in LIBPATH to load any of its DLLs and they would stay loaded.

Quote
I will stop all the servers again and give Firefox a try with todays adjustments in place.

Time passes...

OK. I did that, stopping all servers and it went back to the previous behaviour with the profile manager window disappearing after selecting a profile and taking my mouse pointer with it on the second attempt, but not generating a trap log.

Strange and confounding.

However,  it does appear as if something in one of my startup-server.cmds is having an affect on things for when I restarted them after the above test, the Firefox profile manager window once more exits cleanly and my mouse pointer no longer disappears. What a mess.

An interesting note, on my other machine when I moved the ".;" in my libpath to follow the unixroot paths, Firefox stopped working yielding a popup window that said XUL.DLL could not be loaded.
Firefox once again ran when I moved it back to the beginning of the statement. So, the debate on where that should go has not yet been solved. [/color]

One suggestion is to use cmd files to set up your environment for all your servers. Something like, and this is guess work about your programs,
set PATH=c:\weasel;%PATH%
set BEGINLIBPATH=c:\weasel;%BEGINLIBPATH%
set LIBPATHSTRICT=T
weasel.exe

Adjusting as needed for your various services. This should help with DLL hell