Author Topic: OpenOffice 4.1.3 Draw problem  (Read 12271 times)

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
OpenOffice 4.1.3 Draw problem
« on: January 26, 2017, 08:30:38 pm »
Hi All

Before posting a bug report I thought I'd ask if anyone else sees the same problem when using AOO4.1.3 Draw.

The problem is that any attempt to resize lines/boxes of any sort using the mouse results in an instant crash.

Is this just my systems - all 4 - that this happens on?


Regards

Pete

roberto

  • Hero Member
  • *****
  • Posts: 810
  • Karma: +3/-6
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #1 on: January 27, 2017, 08:18:33 am »
I do not have that problem with Apache oo 413.
But what I'm seeing is that different computers have different problems. In one it happens to me that every approximately one month, I disappear a unit. In that same pc, firefox and thunderbird, corrupt some files sqllite, Preventing the backup. I delete them and everything works fine, but only until they get corrupted again.And in other pc, other problems.
Saludos

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #2 on: January 30, 2017, 04:24:31 pm »
Only one lock-up (hard crash) experience with AOO 4.1.3 Draw...my machine was running for a little over 6 days (24x7, I never shut things down unless I have to)...I just re-started FF38.x (usually about once a day, sometimes less, depending on how much browsing I'm actually doing) because it went down...I then read your post below and went to try it out => HARD..HARD crash...as in no response from anything, re-start switch was the only option!

Keep in mind though, I have my AOO configured to load into HIGHMEM, both the code and data segments...since that crash I reverted to just the code segment. I re-tried this and with FF 38.x up and running Draw behaves as expected...it comes up fine, objects can be created, re-sized, moved, destroyed, no problems.

Do you have the HIGHMEM feature enabled?

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #3 on: January 30, 2017, 08:00:19 pm »
Quote
Do you have the HIGHMEM feature enabled?

I do (and I haven't got around to getting 4.13, yet). I do need to use the quick start feature, to keep it from unloading the DLLs, or I get hard crashes every time I close AOO. I also use VIRTUALADDRESSLIMIT=3072 which gives me lots of upper shared memory. Unfortunately, it still uses some lower shared memory, which usually isn't a problem.

The main problem with lower shared memory is that Firefox eats a lot of it, when it is working properly, and all of it when it gets onto a web page that just keeps on sending data. I have watched the Sentinel Memory Watcher widget increase memory usage to the point where my 4GB system goes almost 200 meg into the swap file, before lower shared memory runs out, and Firefox crashes. It also uses a good chunk of upper shared memory, even though it is set to not use that. At least it is only Firefox that crashes (and that can happen, an hour after I finish using it, even when I leave the page that does it). If I try to use upper shared memory with Firefox, it will run okay, until I try to close it (or it crashes), then it usually takes the whole system down. I don't like to let Firefox run, when I am not watching what it is doing, so I usually close it when I am finished.

There are other things that cause shared memory to run out, and the biggest offender is Firefox (probably because XUL.DLL is so big).

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #4 on: January 30, 2017, 11:14:14 pm »
Quote
Do you have the HIGHMEM feature enabled?

I do (and I haven't got around to getting 4.13, yet). I do need to use the quick start feature, to keep it from unloading the DLLs, or I get hard crashes every time I close AOO. I also use VIRTUALADDRESSLIMIT=3072 which gives me lots of upper shared memory. Unfortunately, it still uses some lower shared memory, which usually isn't a problem.

For some systems, VIRTUALADDRESSLIMIT=3072 is too high and will cause instability. I believe it is hardware dependent as hardware uses memory at the top of the 4GB space and works down. A video card with 1GB of memory for example might limit things.
Quote
The main problem with lower shared memory is that Firefox eats a lot of it, when it is working properly, and all of it when it gets onto a web page that just keeps on sending data. I have watched the Sentinel Memory Watcher widget increase memory usage to the point where my 4GB system goes almost 200 meg into the swap file, before lower shared memory runs out, and Firefox crashes.

That's surprising, must be some memory hungry pages you're loading. Here with 2GBs of ram, I've only hit the swap file when linking XUL.DLL (it also needs the full 3072 MBs of address space)

Quote
It also uses a good chunk of upper shared memory, even though it is set to not use that.

Firefox allocates memory in the high arena and if it didn't you'd be lucky to load a couple of tabs. I'd assume that OO does as well. At that most programs should be linked with the -Zhigh-mem GCC switch to allocate memory high as as long it is pure 32 bit code, it is safe.

Quote
At least it is only Firefox that crashes (and that can happen, an hour after I finish using it, even when I leave the page that does it). If I try to use upper shared memory with Firefox, it will run okay, until I try to close it (or it crashes), then it usually takes the whole system down. I don't like to let Firefox run, when I am not watching what it is doing, so I usually close it when I am finished.

There are other things that cause shared memory to run out, and the biggest offender is Firefox (probably because XUL.DLL is so big).

Have you tried just marking XUL.DLL to load the code or data high? Same with anything else that people have problems with. I know previous releases here were only stable with one or the other (forget which) but not both.

guzzi

  • Sr. Member
  • ****
  • Posts: 331
  • Karma: +0/-0
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #5 on: January 31, 2017, 12:07:06 am »
Only code high is stable. The last time I tested, of the FF dll's only xul.dll wasn't stable with both code and data high.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #6 on: January 31, 2017, 12:18:52 am »
Quote
For some systems, VIRTUALADDRESSLIMIT=3072 is too high and will cause instability. I believe it is hardware dependent as hardware uses memory at the top of the 4GB space and works down. A video card with 1GB of memory for example might limit things.

Actually, that surprises me. I set my antique IBM ThinkPad A22e (256 meg of real memory) to 3072, and I haven't seen a problem. Of course, I don't even bother to try Firefox, or AOO. Well, I did try FF, a while back, and it took about 20 minutes to load the default home page.   :(

Quote
That's surprising, must be some memory hungry pages you're loading.

I have seen it a few times, loading links from TheWeatherNetwork. Specifically from  https://www.theweathernetwork.com/ca/weather/alberta/sherwood-park. I think it may be loading some video stuff, but it doesn't stop when I leave the page, and FlashBlock doesn't stop it. When this happens, lower shared memory drops to zero, and FF crashes. Upper shared memory drops from about 2 GB to about 200 MB (and it would probably crash if that went to zero first). Obviously, FF isn't checking to see if memory is available, before it tries to allocate it. It shouldn't just crash.

Quote
Have you tried just marking XUL.DLL to load the code or data high?

I know that I tried both. I don't remember if I tried them one at a time. I will do so, when I get some time, but I doubt if that would stop the crash.

xynixme

  • Guest
Re: OpenOffice 4.1.3 Draw problem
« Reply #7 on: January 31, 2017, 05:03:18 am »
I set my antique IBM ThinkPad A22e (256 meg of real memory) to 3072, and I haven't seen a problem. Of course, I don't even bother to try Firefox, or AOO. Well, I did try FF, a while back, and it took about 20 minutes to load the default home page.   :(

For the record: memory is not the main cause of it taking about 20 minutes, albeit swapping never helps. The CPU of a.o. the IBM ThinkPad 20-series and the 600X is.

Install 1 GiB in a popular T23, and it still will be far slower than a 600E. If one wants to browse with FF, then use an antique version of the browser, or skip this generation of CPUs. Actually the browser can be reasonably fast after an install. As soon as the problems occurs you're lost. If it took 20 minutes, then nowadays that's normal with an IBM ThinkPad A22e and other 20-series ThinkPads.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #8 on: January 31, 2017, 07:02:57 am »
Quote
For the record: memory is not the main cause of it taking about 20 minutes, albeit swapping never helps. The CPU of a.o. the IBM ThinkPad 20-series and the 600X is.

I disagree. The CPU (a P3) is remarkably fast, when it doesn't have to swap. The disk is not very fast, and swapping brings it to it's knees, for every program that needs to use swapping. Since Firefox (current versions), need so much memory, it needs to swap about 80% of what is in memory, just to display the default home page. Current versions are also not designed to swap efficiently, so it is constantly swapping (usually referred to as "thrashing"). I am using eCS 2.2b2 on it, and performance (when swapping is not needed) is actually quite good. I am pretty sure that it would work much better, if I could put enough memory into it (like 1 GB), but it is maxed out at 256 meg.

Firefox seems to work okay in a VBox system, with 800 meg of memory allocated, on modern computers, but I don't use it much in that configuration. Swapping is also a LOT faster, if needed.

Quote
If it took 20 minutes, then nowadays that's normal with an IBM ThinkPad A22e and other 20-series ThinkPads.

I agree with that statement. Firefox has been slowing down ever since it needed to start swapping (around version 4.0). My point was, that VIRTUALADDRESSLIMIT=3072 works fine with it, and Firefox will eventually get around to displaying a small web page (like HOBBES incoming), if you leave it alone.

The machine is still useable, for certain applications that I need, like HOUSE/2. It also has a real serial port, which is used with that program. More recent laptops rarely, if ever, have that feature.

I would also note, that the machine will sleep, and wake up, which very few modern machines will do with eCS.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #9 on: February 01, 2017, 03:05:02 am »
Hi All

I had not tried using the highmem "feature" to date so gave it a try with the -c option.
A very real improvement: No problem resizing lines/boxes by dragging with the mouse.

With regard to  VIRTUALADDRESSLIMIT=3072 I seem to recall adopting this particular value as the result of something needing it... possibly VirtualBox. Just about the only side effect I have noticed with this value is that SNAP reports the wrong amount of Memory (128Mb) installed on my ATI X550 graphics card - it should be 256Mb.


Regards

Pete

Dave Yeo

  • Hero Member
  • *****
  • Posts: 4787
  • Karma: +99/-1
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #10 on: February 01, 2017, 04:45:51 am »
Hi Pete, you might want to test with your VIRTUALADDRESSLIMIT set 128 (perhaps a bit more) lower, eg 2944 and see if that corrects your video memory.
And everyone should remember that marking DLLs to load high works best with the latest kernel. Rumour has it that ArcaOS is going to include more fixes for loading high in their kernel.

Pete

  • Hero Member
  • *****
  • Posts: 1281
  • Karma: +9/-0
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #11 on: February 01, 2017, 09:26:50 pm »
Hi Dave

I was using VIRTUALADDRESSLIMIT=1536 until fairly recently which seems to be the highest value I can use and also have SNAP report video memory correctly. I'm very sure I changed that value to 3072 around the time I installed Virtualbox which I seem to recall would not start when using 1536. I think the 3072 value was a setting recommended in a discussion about virtualbox 5.0.6 in these forums.

Having SNAP report only half the installed video memory does not seem to be causing a problem - so far - so I can live with that.


Regards

Pete

Andi B.

  • Hero Member
  • *****
  • Posts: 811
  • Karma: +11/-2
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #12 on: February 02, 2017, 09:26:31 am »
You can limit SNAP video memory usage in config.sys to 32MB f.i. with SET SNAPxxxx. This is the setting in the example given in SNAP documentation. You'll never need more than this on OS/2.

Dariusz Piatkowski

  • Hero Member
  • *****
  • Posts: 1317
  • Karma: +26/-0
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #13 on: February 10, 2017, 02:53:36 pm »
I've got my system set to use VIRTUALADDRESSLIMIT=2560 setting.

Given how many HPFS386 partitions I have defined I found that setting this anywhere higher causes some sort of memory error during boot where the volumes are not "mounted"...yeah, strange error, but pretty specific to my hardware configuration.

Doug Bissett

  • Hero Member
  • *****
  • Posts: 1593
  • Karma: +4/-2
    • View Profile
Re: OpenOffice 4.1.3 Draw problem
« Reply #14 on: February 11, 2017, 07:06:44 am »
Just a quick update:

I got AOO 4.1.3, and installed it. I haven't tried draw.

Quote
Quote

    The main problem with lower shared memory is that Firefox eats a lot of it, when it is working properly, and all of it when it gets onto a web page that just keeps on sending data. I have watched the Sentinel Memory Watcher widget increase memory usage to the point where my 4GB system goes almost 200 meg into the swap file, before lower shared memory runs out, and Firefox crashes.

That's surprising, must be some memory hungry pages you're loading. Here with 2GBs of ram, I've only hit the swap file when linking XUL.DLL (it also needs the full 3072 MBs of address space)

An update to this problem:  Firefox popped up the "welcome back" thing, and offered to "clean up" my install. Since I had recently done a backup, I decided to see what it did. It finished successfully, and Firefox has been behaving itself since then. I have NO IDEA what it did, but the problem seems to be solved, for now.