QT5 simplebrowser

[OS4User]

Here, after the last big update to netlabs.rel, my system became very unstable.

Try to rollback nss* and nspr. I have installed almost all packs from  netlabs.rel  -  everything quite stable.

[Dave Yeo]

Here, after the last big update to netlabs.rel, my system became very unstable.

Try to rollback nss* and nspr. I have installed almost all packs from  netlabs.rel  -  everything quite stable.

It's weird, I updated nss* and nspr4 quite a while back on my netlabs-exp partition. The browser started just vanishing, no trp, no popuplog entries and attempting to trace it down was futile. Now on that partition, after updating libc etc, the browser frequently crashes in various places, usually related to committing memory in various places.
This partition using netlabs-rel became very unstable after the big update, fixed partially by lowering my VIRTUALADDRESSLIMIT from 3072 to 2560 but still so frustrating that I formatted it and restored a backup, back to stability.
Seems that a combination of the libc and NSPR4 and NSS updates led to the extreme instability. Previously I had tried the newer NSPR4 and NSS on this partition and had the vanishing browser thing so rolled back.
I've also tested by rebuilding the browser with the updated NSPR4 and NSS and things were stable.
So now I'm testing rebuilding NSPR4 and NSS and just replaced the NSPR4 DLL's as a test. So far things seem stable.
I continue testing and updating the other files. Anyone who wants to play along, here's my newly built NSPR4 DLL's, they're Pentium 4 with -mtune=generic raw builds, so still have the debugging stuff included, could be lxlited, my build didn't create dbg files for these. Unlock and replace the ones in @unixroot/usr/lib and reboot to use them. Haven't tried marking them for high memory yet. If you want to revert, use ANPM or YUM to reinstall.
Be good if someone testing the Otter beta tests too.

[OS4User]

Here, after the last big update to netlabs.rel, my system became very unstable.

Try to rollback nss* and nspr. I have installed almost all packs from  netlabs.rel  -  everything quite stable.

Anyone who wants to play along, here's my newly built NSPR4 DLL's, they're Pentium 4 with -mtune=generic raw builds, so still have the debugging stuff included, could be lxlited, my build didn't create dbg files for these.

Hi Dave,

I have been testing your newly built NSPR4 DLL's for about 6 hours. My FF became unstable - during this time it suddenly closed 5 times. Prior to upgrading to the new NSPR4, my FF would suddenly close once in a few weeks.

[Dave Yeo]

Hi Dave,

I have been testing your newly built NSPR4 DLL's for about 6 hours. My FF became unstable - during this time it suddenly closed 5 times. Prior to upgrading to the new NSPR4, my FF would suddenly close once in a few weeks.

Are you using the updated NSS 3.47.0-2 along side it? They're matched and simply replacing NSPR-4.12 would be a bad idea. Sorry for not being clear about that.

[OS4User]

Hi Dave,

I have been testing your newly built NSPR4 DLL's for about 6 hours. My FF became unstable - during this time it suddenly closed 5 times. Prior to upgrading to the new NSPR4, my FF would suddenly close once in a few weeks.

Are you using the updated NSS 3.47.0-2 along side it? They're matched and simply replacing NSPR-4.12 would be a bad idea. Sorry for not being clear about that.

I am using:  NSPR 4.12.0-4 and NSS 3.23.0-4.

Once I tried   4.23.0-1 and 3.47.0-2 respectively (when they were in EXP)  - my FF become to unstable.

I tested your NSPR with NSS 3.23.0-4.

[Roderick Klein]

Here, after the last big update to netlabs.rel, my system became very unstable.

Try to rollback nss* and nspr. I have installed almost all packs from  netlabs.rel  -  everything quite stable.

It's weird, I updated nss* and nspr4 quite a while back on my netlabs-exp partition. The browser started just vanishing, no trp, no popuplog entries and attempting to trace it down was futile. Now on that partition, after updating libc etc, the browser frequently crashes in various places, usually related to committing memory in various places.
This partition using netlabs-rel became very unstable after the big update, fixed partially by lowering my VIRTUALADDRESSLIMIT from 3072 to 2560 but still so frustrating that I formatted it and restored a backup, back to stability.
Seems that a combination of the libc and NSPR4 and NSS updates led to the extreme instability. Previously I had tried the newer NSPR4 and NSS on this partition and had the vanishing browser thing so rolled back.
I've also tested by rebuilding the browser with the updated NSPR4 and NSS and things were stable.
So now I'm testing rebuilding NSPR4 and NSS and just replaced the NSPR4 DLL's as a test. So far things seem stable.
I continue testing and updating the other files. Anyone who wants to play along, here's my newly built NSPR4 DLL's, they're Pentium 4 with -mtune=generic raw builds, so still have the debugging stuff included, could be lxlited, my build didn't create dbg files for these. Unlock and replace the ones in @unixroot/usr/lib and reboot to use them. Haven't tried marking them for high memory yet. If you want to revert, use ANPM or YUM to reinstall.
Be good if someone testing the Otter beta tests too.

I just have one question has there ever been any hard evidence for fiddeling with the virtual address limit really increases or decreases applications stability ? As in something of debug trace to point that this *actually* trace. To be honest I have a hard time feeling this contributes to making applications stable or more stable.

I can see where increasing the amount of virtual memory you can have an application leak memory longer. But reducing virtual address limit ?

Roderick

[roberto]

Hello
According to I saw the NSPR * I consider the vibration of OS /2 which is 31.25 Hercios.
And probe with this value in
SET NSPR_OS2_NO_HIRES_TIMER=0.0003125

I have it proven very little, but I was hung once the computer. But I think it is for an excess of temperature 98-99 degrees centigrado.
Doing system overload tests.
The graphic test of the Sysbench was improved by 11% from 74,000 to 65000 in a 17 inches.
I think this can be interesting, maybe not for the stability you are looking for

Saludos

[OS4User]

I just have one question has there ever been any hard evidence for fiddeling with the virtual address limit really increases or decreases applications stability ?

I always use VAL = 3072. I have never seen corelation between VAL value and system/applications stability. System may not boot if:
  - VAL = 3072 (means System Aria is just 1GB);
  - and too many drivers;
  - and JFS cache is not correctly set;
  - and treads/processes are not correctly set;
such cases I have meet a few times.

[Dave Yeo]

Seems I did have one system where it did seem to make a difference, but maybe I'm misremembering. In this case it may well have been a coincidence where the reboot fixed things.
I'm not sure if IBM finished the high memory support and a theory is that too high a VAL value on some hardware might intrude into kernel memory space. This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc. I'd assume a video card could eat up more memory at the top end.

[Dave Yeo]

Hello
According to I saw the NSPR * I consider the vibration of OS /2 which is 31.25 Hercios.
And probe with this value in
SET NSPR_OS2_NO_HIRES_TIMER=0.0003125

I have it proven very little, but I was hung once the computer. But I think it is for an excess of temperature 98-99 degrees centigrado.
Doing system overload tests.
The graphic test of the Sysbench was improved by 11% from 74,000 to 65000 in a 17 inches.
I think this can be interesting, maybe not for the stability you are looking for

Saludos

For NSPR_OS2_NO_HIRES_TIMER, it only matters whether it is set or not and only affects programs using NSPR4, mostly the Mozilla apps though IIRC, VirtualBox also uses it. Here's the code from nsprpub/pr/src/md/os2/os2inrval.c,

Code: [Select]

    if ((envp = getenv("NSPR_OS2_NO_HIRES_TIMER")) != NULL) {
        if (atoi(envp) == 1)
           return;
    }


[OS4User]

This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc

VAL and virtual memory do not have any relation to physical memory. System will have exactly the same layout and amount (about 4GB) of virtual mem whether it has 4GB or 512MB of RAM installed.

[Roderick Klein]

Seems I did have one system where it did seem to make a difference, but maybe I'm misremembering. In this case it may well have been a coincidence where the reboot fixed things.
I'm not sure if IBM finished the high memory support and a theory is that too high a VAL value on some hardware might intrude into kernel memory space. This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc. I'd assume a video card could eat up more memory at the top end.

Few people know that this virtualaddresslimit was already build into Warpserver advanced. It was only later this code was moved into the _W4 kernel. In my book the code is finished. IBM introduced high memory for stuff such as DB2, which could use this high memory.
Now does the code contain bugs, possible. But we need to have proper debug data for that.

Roderick

[Dave Yeo]

This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc

VAL and virtual memory do not have any relation to physical memory. System will have exactly the same layout and amount (about 4GB) of virtual mem whether it has 4GB or 512MB of RAM installed.

4GB's of address space minus PCI memory address space (including video memory) equals 3.2Mb's of address space in my case, and then minus kernel address space, things like the JFS cache. As Dariusz mentioned in a separate thread, he had to lower VAL when he enlarged the JFS cache to get the larger cache to take.
I also discovered that with 1.5GB's of ram and VAL set to 3072, the swap file is limited to 2GB's of virtual memory, likely due to signed variables somewhere. The crash said swap file full even with lots of disk space on a JFS volume. Linking xul back around FF10 really did need the full address space.

[Dave Yeo]

Seems I did have one system where it did seem to make a difference, but maybe I'm misremembering. In this case it may well have been a coincidence where the reboot fixed things.
I'm not sure if IBM finished the high memory support and a theory is that too high a VAL value on some hardware might intrude into kernel memory space. This system for example has 3,241 MB's memory accessible to the system, which doesn't leave much room above 3072 VAL value for the JFS cache etc. I'd assume a video card could eat up more memory at the top end.

Few people know that this virtualaddresslimit was already build into Warpserver advanced. It was only later this code was moved into the _W4 kernel. In my book the code is finished. IBM introduced high memory for stuff such as DB2, which could use this high memory.
Now does the code contain bugs, possible. But we need to have proper debug data for that.

Roderick

I thought it was introduced in WarpServer and at first only 2GB's before being extended to 3GB's.
As for bugs, seems most of the kernel fixes since IBM left development have been high memory related, as well as the undocumented problems with parts of the OS/2 API not working with high memory, see os2safe.h for the current list. Many were found the hard way when we started using high memory for Mozilla.
It is easy to believe there are other bugs somewhere. Even Windows 32bit discouraged using more then 2GB's of address space, though I believe mostly due to buggy device drivers using signed ints

Edit: I'll also add that Arca Noae has decided on a 1536 default for VAL. When I asked Lewis about it, he just commented that they figured it was safer. Can't remember if he said it was from experience or just due to caution.

[OS4User]

4GB's of address space minus PCI memory address space (including video memory) equals 3.2Mb's of address space in my case, and then minus kernel address space, things like the JFS cache.

Dave, you've mixed all together .  Yes, you can see 3.2GB of total RAM accessible to system  (even if 4 GB of SIMM modules are installed) because of PCI dev, BIOSes, APICs, HPET and video adapter (may be something else). But this is physical mem. Kernel operates by 32 bit phys address only - that is why 4GB  can be addressed and no more.

All virtual mem in summary is always 4GB in spite of how much physical mem you have.

Virtual memory is divided into tree parts:
 - low (under 512M) (private and shared)
 - hight (between 512M and VAL)(private and shared)
 - system (between VAL and 4GB)

PDDs, FSDs, PSD, kernel, loader, JFS cache and many other things  are in system memory.

Use of system memory almost doesn't grow after boot.

System compensates lack of RAM by swap file.