09-18-2023, 10:08 PM (This post was last modified: 09-18-2023, 10:10 PM by Dav.)
I'd guess it's all those Pixel(x, y).soft = _NewImage(1, 1, 32) images which aren't freed up? When I add a _FreeImage Pixel(x, y).soft at the end (just before the NEXT x) it doesn't crash.
(09-18-2023, 10:08 PM)Dav Wrote: I'd guess it's all those Pixel(x, y).soft = _NewImage(1, 1, 32) images which aren't freed up? When I add a _FreeImage Pixel(x, y).soft at the end (just before the NEXT x) it doesn't crash.
- Dav
Yep, you're right, how odd. However, I want to keep the software version of the pixel too for the demo I have in mind. Hmm, I'll play around with this.
New to QB64pe? Visit the QB64 tutorial to get started. QB64 Tutorial
Ok, even if I try to create 1280x720 (921600) individual software images of 1x1 pixel with nothing else going on the program still crashes at random points. Something is not right here.
New to QB64pe? Visit the QB64 tutorial to get started. QB64 Tutorial
I have written a similar program and became convinced QB64PE doesn't like arrays of an user-defined type involved with long integers to be used for image handles.
On Slackel Linux, I wrote a program which was supposed to take a screenshot of the desktop at the time (clumsily with "scrot" command-line tool) and do a "meltdown" business like stuff from that cheap "Matrix" movie that keeps being recalled. Now I have to go find that program in my backups. It works now, because I was forced to allocate a separate array of long integers to hold the image handles, apart from an array of an UDT.
This contribution is actually useless in this thread but I had to voice it out.
I can't open nearly that many 1x1 images either. Here's code I was playing with. When I increase the image size it crashes quicker too, so there is a memory limit I'm reaching. So It may be just the regular running out of memory issue. But why that limit is different for different runs I dunno, maybe an OS memory management thing? I'm just throwing out guesses....
- Dav
Code: (Select All)
Screen _NewImage(800, 600, 32)
Dim img&(500000)
For t& = 1 To 500000
Print t&
img&(t&) = _NewImage(1, 1, 32) 'increase pix size, it crashes quicker.
Next
I modified the above program to add a `_LIMIT 10000` inside the loop, and caused it to print every 1000 iterations. It gave up at about 300 thousand. But I needed to keep Firefox in memory and myself logged into this site, so...
09-19-2023, 12:22 AM (This post was last modified: 09-19-2023, 12:22 AM by DSMan195276.)
Unfortunately it's just a pretty straight forward bug in QB64, you can see it here.
Basically what's happening is that the program starts with a buffer that can hold 4096 images, and once you create more than that it will "resize" the buffer to be larger by another 4096. That resize process involves creating a new buffer, copying the contents, and then freeing the previous buffer. The code does attempt to update the pointers to images, hence the `update existing img pointers to new locations` comment, but unfortunately that's not good enough because the display thread is using `display_page` with no synchronization. The end result is that the display thread can end up reading from `display_page` when it still points to the old free'd buffer of images and that leads to it randomly blowing up.
I can't offer an actual fix at the moment beyond just avoiding that many images, but if you change `IMG_BUFFERSIZE` in `libqb.cpp` to be larger than the number of images your program will use then you can avoid the issue.