Firefox error message

[Joop]

Yesterday I downloaded the new JAlbum. Its grown from about 18.5Mb to about 169Mb. You get 30 days to play with it and after that you need a license. In the zip also chromium browsers and this will give an error if JAlbum wants to use it. But there is in the preferences a choice for internal or external browsers, so internal set to off. Now the external browser is used and for OS/2-eCS this is Firefox. Up to the test I had Firefox 6.02 as browser. But we have more up to date FF with at least FF 17.01.1. So set it up that JAlbum have to use this FF, but as soon as it needs the browser I get an error from Firefox with the message "Couldn't load xpcom.dll". Is this a missing item in Odin?,  is it just that simple to copy xpcom.dll from an Windows xp installation in the Odin\system32 directory?, or will it just not work because it has to be an xpcom.dll but rebuild for Odin? Can someone help me with this?

[Joop]

Seems to be a bigger thing which also shows up in other OS. Tried clean up, didn't help. If you do this a map named "old firefox data" is created on your desktop. Its big. After done so started JAlbum, but as soon as it needed FF the same message appears. Will be continued as usual....

[Joop]

Xpcom.dll is something from within the directory of FF, so no Windows shit. But in FF17 xpcom.dll is present, FF17 loads normally, matter of fact I'm working with it right now.
So I did a few tests. Does other FF have the same problem. Its not that easy. After installing FF10 latest as browser nothing happened, FF10 doesn't understand if a file is send to it. Okay, lets try FF24. Rebuild the command file for use with FF24. Started JAlbum and I get the message can't load xul.dll. That file is present, but about 10Mb more in size than found with FF17. So here we might have a problem of a memory issue, I only have 1G on board and Java has to see real memory.
In the mean time, real sick joke :-(. Lets see what I can find out more about xpcom.dll. Now I do understand why FF is so high in version number....

[Joop]

Didn't find a real solution for xpcom.dll. FF is installed (if you can speak of installation) in a new created directory and through the program itself all plugins and add-ons installed. I'm working with it right now and don't have any or get any messages that something is not right. So its the combination of two programs and that's make things complicated.

I've tested latest JAlbum with FF 6.02 as an external browser and that works, ie the browser is started and the page is loaded, but if your happy with the contents is another question and is not the problem of the browser. So for now latest payed version of JAlbum seems to work without integrated browser and as external browser FF 6.02.

[Dave Yeo]

Yesterday I downloaded the new JAlbum. Its grown from about 18.5Mb to about 169Mb. You get 30 days to play with it and after that you need a license. In the zip also chromium browsers and this will give an error if JAlbum wants to use it. But there is in the preferences a choice for internal or external browsers, so internal set to off. Now the external browser is used and for OS/2-eCS this is Firefox. Up to the test I had Firefox 6.02 as browser. But we have more up to date FF with at least FF 17.01.1. So set it up that JAlbum have to use this FF, but as soon as it needs the browser I get an error from Firefox with the message "Couldn't load xpcom.dll". Is this a missing item in Odin?,  is it just that simple to copy xpcom.dll from an Windows xp installation in the Odin\system32 directory?, or will it just not work because it has to be an xpcom.dll but rebuild for Odin? Can someone help me with this?

The xpcom missing thing is a general error which was fixed but seems to have somehow got reverted 
The real problem is that you are missing something else, pthreads (pthr01.dll) mmap.dll, gcc444.dll, stdcpp6.dll or another gcc dll that one of the above depends on as well as the mzfntcfgft package. Easiest is to download moz_required_dlls_v1 and the newest mzfntcfgft from Hobbes.

[Joop]

Dave, thank you for your answer,

The xpcom missing thing is a general error which was fixed but seems to have somehow got reverted 
The real problem is that you are missing something else,

pthreads (pthr01.dll)  installed
mmap.dll installed
gcc444.dll installed
stdcpp6.dll  installed
another gcc dll , you have to be more precise  than this
mzfntcfgft package  installed
moz_required_dlls_v1  installed
the newest mzfntcfgft  that is? installed 20130104, but there is also a mzfntcfgft_infinality_b2.zip, which is an alternative, sounds not to me as a must have.
The dll's are installed over OS/2 and eCS DLL directories. Of course both in libpath.

In case you forget, I just work right now with FF 17.0.11esr without any error so far. Only get the message in combination with JAlbum.

[Dave Yeo]

Sorry Joop, read to fast and missed the part where FF17.0.11 was running fine.
All I can think of is that something is running out of memory. You might want to try increasing your virtualaddresslimit to 2048 or even 2500. Be sure to have an alternate boot method in case of problems.
You are likely to get excessive swapping though and if this is the problem I'm somewhat surprised nothing crashed.
As you noticed the newer the Firefox, the bigger (dmik had to way up his virtualaddresslimit just to link xul.dll for 24) and the more memory that is used. With 64bit systems becoming popular this is only going to get worse.
BTW, do you have the icetea (Java6) plugin installed? Perhaps it is an interaction with that.

[ivan]

Joop, as far as I can see jAlbum 12-1-9 is not that much different to jAlbum 11-4-1.  The differences are the builtin browser and having to pay for it so, unless there is some absolute 'must have' improvement in future releases I am sticking with 11-4-1.

[Joop]

Hello Dave,
Thanks for your answer,

Sorry Joop, read to fast and missed the part where FF17.0.11 was running fine.

Can happen, things are getting more complicated and you need more text for explaining when it doesn't go the way it should.

All I can think of is that something is running out of memory. You might want to try increasing your virtualaddresslimit to 2048 or even 2500. Be sure to have an alternate boot method in case of problems.
You are likely to get excessive swapping though and if this is the problem I'm somewhat surprised nothing crashed.
As you noticed the newer the Firefox, the bigger (dmik had to way up his virtualaddresslimit just to link xul.dll for 24) and the more memory that is used. With 64bit systems becoming popular this is only going to get worse.
BTW, do you have the icetea (Java6) plugin installed? Perhaps it is an interaction with that.

Yes, I noticed the big difference with xul. No, I have not installed icetea, so far no need for. Have to find out. Most of the times when I'm testing I only have the test subject running and nothing else, so may be this is your answer why its not crashing. For your information - it must be somewhere in OS/2 - if the system runs out of memory, and I really mean ALL of it, so no room in memory, no room on all hard disks or other storage, the system will come up with the message that its short of memory and if you like to install a storage medium so the system can go on with the task. I have seen this message only once on a 386 system with OS/2 2.11.  So crashing surprises me, will become very slow, but not going down.

[Joop]

Joop, as far as I can see jAlbum 12-1-9 is not that much different to jAlbum 11-4-1.  The differences are the builtin browser and having to pay for it so, unless there is some absolute 'must have' improvement in future releases I am sticking with 11-4-1.

Ivan, thanks for the remark, but its not fully true. JAlbum 12.1.9 does have a few things more and is faster. I just test Java programs for OS/2-eCS users and have a website about it. I can't test all, special then when a server is needed. I'm very busy the last few years and work is piling up, so the website is a little behind in maintenance. Right now busy with the English version of Java, its not online yet. Also have strange effects with ImageJ, for some reason update gives a strange error. But testing is sometimes difficult because the number of combinations of Odin and Java is going up. There is good news too, this week I got the source from a program, but with the restriction not to give it away. So finally I have to dive into programming, did I say I was busy?

[Dave Yeo]

All I can think of is that something is running out of memory. You might want to try increasing your virtualaddresslimit to 2048 or even 2500. Be sure to have an alternate boot method in case of problems.
You are likely to get excessive swapping though and if this is the problem I'm somewhat surprised nothing crashed.
As you noticed the newer the Firefox, the bigger (dmik had to way up his virtualaddresslimit just to link xul.dll for 24) and the more memory that is used. With 64bit systems becoming popular this is only going to get worse.
BTW, do you have the icetea (Java6) plugin installed? Perhaps it is an interaction with that.

Yes, I noticed the big difference with xul. No, I have not installed icetea, so far no need for. Have to find out. Most of the times when I'm testing I only have the test subject running and nothing else, so may be this is your answer why its not crashing. For your information - it must be somewhere in OS/2 - if the system runs out of memory, and I really mean ALL of it, so no room in memory, no room on all hard disks or other storage, the system will come up with the message that its short of memory and if you like to install a storage medium so the system can go on with the task. I have seen this message only once on a 386 system with OS/2 2.11.  So crashing surprises me, will become very slow, but not going down.

There's memory and there's memory. Usually the crashes are related to running out of shared low memory. There's also really running out of memory including swap space which results in the system stopping with a message about the swap file being full or such.
What I'm thinking is that something is requesting a large block of memory and the system is responding to the program that it can't allocate it. No crash, just a failure. I've seen similar while compiling FF, there's one file that takes 800+MBs to compile and when I had virtualaddresslimit set at 1024, GCC (or G++) died with an out of memory error. In that case increasing virtualaddresslimit fixed it though when I only had  a GB of memory there could be a lot of swapping.

[ivan]

Joop, as far as I can see jAlbum 12-1-9 is not that much different to jAlbum 11-4-1.  The differences are the builtin browser and having to pay for it so, unless there is some absolute 'must have' improvement in future releases I am sticking with 11-4-1.

Ivan, thanks for the remark, but its not fully true. JAlbum 12.1.9 does have a few things more and is faster. I just test Java programs for OS/2-eCS users and have a website about it. I can't test all, special then when a server is needed. I'm very busy the last few years and work is piling up, so the website is a little behind in maintenance. Right now busy with the English version of Java, its not online yet. Also have strange effects with ImageJ, for some reason update gives a strange error. But testing is sometimes difficult because the number of combinations of Odin and Java is going up. There is good news too, this week I got the source from a program, but with the restriction not to give it away. So finally I have to dive into programming, did I say I was busy?

If you are like me busy is a slight understatement.  Actually I didn't note any real speed improvement, but then I was using a 4 core AMD processor running at 3 Ghz and I had 4GB memory and some rather fast disks.  I have no problems with ImageJ 1.48.  It is a little better than 1.47.

Best of luck with the programming.  The last time I did any was about 30 years ago and that was assembler.

[Joop]

After some tests with different ImageJ versions, including the ones which always run without problems, I got with all versions the same panic message. This is not normal, because also some ImageJ versions which did run gave now the same error message. So what was changed on my system?

To begin with I renamed my Odin directory to Odin-old and made a new Odin directory. I copied a previous version of Odin to that directory because I was running latest version. After Odininst.exe I run again my cmd file for starting ImageJ. It did start and for testing I go to help for updating ImageJ to latest. Instead of the panic reaction it started with the menu which version I wanted. That's the right menu and I did exit on that and on ImageJ. I deleted the contents of Odin and copied latest version to it, Odininst.exe and again restart ImageJ. Did go to help, fingers crossed, no panics and I got the update menu and did  the update.

What's in the Odin-old directory?
Next I compared Odin with Odin-old. In the Odin-old I had more files, probably because I had failures with other testing like running a program. I found that I had copied some files from Odin-77 to the directory which had to do with PE. Also some other Windows files. Did a virus check with ClamAV but nothing found, all okay.

Okay, ImageJ is running like before, but may be those found "alien" files may be responsible for the problems with the combination of JAlbum and FF. First tried with JAlbum latest with FF17.0.11 gave no response. Duh.. Reprogrammed the command file from JAlbum so FF 6.02 has to be used. Did start JAlbum, did a F12 for preview and FF came up with a nice page, even better than before. Did exit all and again reprogrammed the command file from JAlbum to work with FF 17.0.11. Restart, but nope, message "Couldn't load xpcom.dll" appeared in a popup. JAlbum crashed or did go exit the fast way so to speak. Again reprogrammed the command file, now I did cut back the memory for JAlbum from 400 to 300. After saving did restart JAlbum, after loading the test album I had 830Mb left, but FF 17.0.11 refuses and gave the popup message. So, I doubt that it has to do with memory, sometimes I have more occupied when I'm busy with my homepage and even then FF starts.