.NET MAUI

126 readers

1 users here now

founded 1 year ago

MODERATORS

Intermittent MAUI Android issue - "The paging file is too small for this operation to complete (DOS error/errno=1455)" (self.dotnetmaui)

submitted 11 months ago by SmartmanApps to c/dotnetmaui

4 comments fedilink hide all child comments

I've just had this happen (and then stop again) for the second time in a few weeks. This is a new MAUI app where the only thing I've changed so far, other than add a few of my own (already previously tested and working) libraries, is change the home page, and the new home page only has a couple of labels on it, so it has no complexity at all added to it yet, and yet getting this odd alleged memory issue. The first time it happened I couldn't find a fix for it, left it for a while, came back (a week's worth of reboots later) and it was working again. Then today I made one trivial change - added a debug write - and the problem came back (but got past the new line without any issues). Then I rebooted and it's working again.

I have 32Gb of RAM, with 12Gb allocated to a RAMdisk, and I have my paging files set to use the RAMdisk.

It generated a log file which said...

"Native memory allocation (mmap) failed to map 186646528 bytes for G1 virtual space"

...so it only needed 180Mb, and down near the bottom it says...

"Memory: 4k page, system-wide physical 32579M (3638M free)"

...so I had more than enough space left (so the memory message may be a red herring for whatever did cause the crash). Googling that first message brings up a bunch of matches, but none of which are for MAUI Android (all different cases with different fixes).

This is using the Android emulator on a Windows machine where I've set the paging sizes to be system-managed. I'm not sure where the Android emulator actually gets memory from though - the system RAM? The paging RAM(disk)? The build directory? The user's App directory?

It reminds me of years ago there was a similar issue with Xamarin Android where the fix/workaround was to add a line to the csproj (I think it increased the heap or something from memory), but I haven't seen that pop up in a long time. Not sure if this is the same issue or a different one.

There's no repro for it cos I can't even reliably repro it. I'm just concerned that it's going to keep coming back given I haven't even added any complexity to it yet.

Has anyone run into this and/or knows how to fix it?

top 4 comments

sorted by: hot top controversial new old

[–] SmartmanApps 1 points 11 months ago

I had this happen again today, so wasn't a one-off glitch. Fortunately it recovered again the next time I ran it. I suspect it MAY have been triggered by my app crashing with an unhandled exception (I didn't notice at the time that this same error message had popped up - I was more concerned with looking into the cause of the exception, and there were some reboots along the way, so that may or may not have been what fixed it).

[–] samus7070 1 points 11 months ago (1 children)

I don’t know the answer but I can say that it is strange to have your paging files use a RAM disk. The whole point of a paging file is to be able to use more extend the amount of ram you have by utilizing a physical disk. What you’re telling the os to do is reserve a bunch of ram for a disk and then if you run low on ram just put some of the data over here in the ram it isn’t allowed to use. Then when it needs the data in the padding file it will have to swap ram pages from memory into the other area of memory and move the needed pages into the non disk memory. It’s very inefficient.

[–] SmartmanApps 1 points 11 months ago

"The whole point of a paging file is to be able to use more extend the amount of ram" - when you have 32Gb of RAM, you don't need to extend it (and I demonstrably hadn't run out of RAM as per the log). What I find strange is apps that are using HDD caches when even off-the-shelf systems have 8Gb of RAM - we're not living in the days of 640k of memory anymore (all my caches are set to use the RAMdisk too). P.S. it's worth the effort because there's a visible improvement in performance.

[–] SmartmanApps 1 points 10 months ago

I'm building up quite a collection of these (I only deleted the first one, and have noticed I've got a lot more now), so this is far from being a once-off thing. In other word,s still looking for any ideas about how to fix this