Webpositive - possible memory leak with especific website

[un_spacyar]

When browsing the following site:

www.pixfans.com

suddently the cpu and memory goes to 100%. After that, the system went unresponsible.

Attach the syslog

Tested in x86_gcc2 hrev49663

[ttcoder]

Someone Cc me to this ticket please

I get this about twice a week on my "tower", tough never with my thinkpad laptop (both running 49662).

It's always in WebPositive, so didn't think much of it yet. Not reproducible easily (the same websites will sometime trigger it, sometime not). Most of the time I notice the problem quick enough (before it becomes impossible to move the mouse pointer completely) that I can drag the mouse pointer to the deskbar and do the "Vulcan Death Grip" on WebPositive, and then the memory usage bar (processcontroller) turns back from red to normal color and sluggishness disappears, all back to normal.

Whenever that happens I get the very same output in syslog, though less extensive due to quick killing of Web+

Once I had said output prefixed with one line like malloc() of 2xxxxxxx bytes asked as in #12397 but it never happened again, so maybe it's not related. FWIW I remember being curious and converting the 2xxxxxx decimal value to hex and it was 0x8000002d or so, which is not a valid error code according to /bin/error (I was hoping to evidence that malloc was passed directly the value of a function that might return an error code, -- bad! bad! bad! :-) -- but my hypothesis does not seem valid, oh well)

[pulkomandy]

On a 32 bit system, a malloc bigger than 2GB will always be rejected because that's the whole address space available to one app. You can "reasonably" allocate about 1.7GB in one chunk, anything bigger will most likely fail. In that case malloc will return NULL, and not steal all the memory.

If your system has more than 2GB of memory, Web+ would fail after allocating his 2GB, and then the rest of the RAM would still be available to others. This should not lead to a complete system crash, unless the app_server is also allocating lots ofthings (BBitmaps for example), in that case the app_server could freeze or crash.

Looking at your syslog, I see a lot of errors from the USB drivers. Where does this come from? Are you running Haiku from USB? I'm guessing a bit but a possible scenario is:

• Haiku is low on memory and tries to use the swap
• The swap is on an USB volume, but there are problems in the USB drivers making things very slow as there are lots of write failures
• Eventually the physical memory gets full as things are not flushed to swap fast enough.

[un_spacyar]

Hello. I will try to complete the information:

About the USB errors: No. I'm not booting Haiku from USB. I'm using Haiku on an standar hard disk instalation. The USB errors is from a USB hub/card reader. If is necessary, I could test again, without the USB card reader plugged.

About the RAM memory, I have 1.5 GB.

Please, tell me if you need more tests or information.

[un_spacyar]

Well, I tried again, but without the USB hub/card reader plugged. In this case, I cant reproduce the error.

Probably, there are some relation between. However, I'm using Haiku on a standard hard disk (also the swap file).

[ttcoder]

I thought about this ticket after reading the log of ​this part of 49944 but that might be a stretch.. And the runtime_loader is too hardcore for me to understand if that part of the code is exercised during the application's launch time only (thus making my comment irrelevant) or also during the rest of the app's lifetime?

At any rate that bug went back to lurking a few updates ago /for me/, that is, even before 49944, so cannot do testing for the OP any more for now..

EDIT: ok just saw this in 49974, so 49944 did not help.. Not certain that what i'm seeing is the same bug as OP, but seems related:

KERN: low resource pages: note -> normal
KERN: 0xf0dcc7f8->VMAnonymousCache::_Commit(619184128): Failed to reserve 13369344 bytes of RAM
KERN: 10721: DEBUGGER: resampling failed
KERN: low resource memory: critical -> warning
KERN: debug_server: Thread 10721 entered the debugger: Debugger call: `resampling failed'
..
KERN: low resource memory: warning -> critical
KERN: 0xf2673260->VMAnonymousCache::_Commit(67108864): Failed to reserve 67108864 bytes of RAM
KERN: 0xf26731d0->VMAnonymousCache::_Commit(30715904): Failed to reserve 30715904 bytes of RAM

[cocobean]

No memory leak or high CPU/thread usage issue during WebPositive testing with haikuwebkit 1.6.9 on hrev53024 x86_gcc2. Please retest.

[nielx]

Assign tickets with status=closed and resolution=fixed within the R1/beta2 development window to the R1/beta2 Milestone