gauthiier/RefractiveIndex
1
0
Fork 0
Code Issues 1 Pull Requests Releases Wiki Activity

windows saving trick bombs memory #7

New Issue
Closed
opened 2018-11-11 17:40:10 +01:00 by gauthiier · 13 comments
gauthiier commented 2018-11-11 17:40:10 +01:00
Owner
Copy Link

Author: @gauthiier Posted at: 25.02.2012 15:22

the windows saving loop (in save_cb) shoot memory off the roof!

i've been profiling with OSX and memory keeps on shooting up - which could explain the "freeze" of the application after 10 minutes on windows.

unsigned char * somePixels;
ofPixels appPix = RefractiveIndex::_pixels;
somePixels = new unsigned char [appPix.getWidth()*appPix.getHeight()*3];
somePixels = appPix.getPixels();

ofImage myImage;
//myImage.allocate(appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR);

//his needs to be here for OSX of we get a BAD ACCESS ERROR. DOES IT BREAK WINDOWS? //
myImage.setUseTexture(false);

myImage.setFromPixels(somePixels,appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR);
myImage.saveImage(ofToDataPath("")+ _whole_file_path_analysis+"/"+file_name);

trying to fix this with "delete somePixels;" yet not conclusive...

Author: @gauthiier Posted at: 25.02.2012 15:22 the windows saving loop (in save_cb) shoot memory off the roof! i've been profiling with OSX and memory keeps on shooting up - which could explain the "freeze" of the application after 10 minutes on windows. ``` unsigned char * somePixels; ofPixels appPix = RefractiveIndex::_pixels; somePixels = new unsigned char [appPix.getWidth()*appPix.getHeight()*3]; somePixels = appPix.getPixels(); ofImage myImage; //myImage.allocate(appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR); //his needs to be here for OSX of we get a BAD ACCESS ERROR. DOES IT BREAK WINDOWS? // myImage.setUseTexture(false); myImage.setFromPixels(somePixels,appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR); myImage.saveImage(ofToDataPath("")+ _whole_file_path_analysis+"/"+file_name); ``` trying to fix this with "delete somePixels;" yet not conclusive...
gauthiier commented 2018-11-11 17:40:12 +01:00
Author
Owner
Copy Link

Author: @heavyside Posted at: 25.02.2012 15:41

we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing.

i don't think it's a memory bloat problem - the software doesn't freeze, it 'dies'. it's not slowing down, it's getting an error. and it doesn't consistently crash after 10 minutes - that's just the longest I've ever seen it run. it crashes sometimes right away, sometimes after 2 minutes, sometimes after 7 minutes. totally random timings, i think.

BTW - it does the same thing on OSX, just less frequently - if you let it run... it eventually crashes as well, probably for the same reason.

i'm fairly sure that the crashes are coming from the openframeworks saves not being thread safe and getting interrupted - so that the save can't finish, and it can't find "FIBITMAP from ofPixels". so this just happens sometimes - when there is an interrupt at the wrong time, randomly. this is the error on crash in Windows:

"unable to get FIBITMAP from ofPixels"

Tom is trying to integrate this today to see if it makes a difference - right Tom?
http://forum.openframeworks.cc/index.php?topic=1687.0

Author: @heavyside Posted at: 25.02.2012 15:41 we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing. i don't think it's a memory bloat problem - the software doesn't freeze, it 'dies'. it's not slowing down, it's getting an error. and it doesn't consistently crash after 10 minutes - that's just the longest I've ever seen it run. it crashes sometimes right away, sometimes after 2 minutes, sometimes after 7 minutes. totally random timings, i think. BTW - it does the same thing on OSX, just less frequently - if you let it run... it eventually crashes as well, probably for the same reason. i'm fairly sure that the crashes are coming from the openframeworks saves not being thread safe and getting interrupted - so that the save can't finish, and it can't find "FIBITMAP from ofPixels". so this just happens sometimes - when there is an interrupt at the wrong time, randomly. this is the error on crash in Windows: "unable to get FIBITMAP from ofPixels" Tom is trying to integrate this today to see if it makes a difference - right Tom? http://forum.openframeworks.cc/index.php?topic=1687.0
gauthiier commented 2018-11-11 17:40:12 +01:00
Author
Owner
Copy Link

Author: @heavyside Posted at: 25.02.2012 15:41

Chris OShea's recommendations at Reply 13 here:

http://forum.openframeworks.cc/index.php/topic,8729.0.html

Author: @heavyside Posted at: 25.02.2012 15:41 Chris OShea's recommendations at Reply 13 here: http://forum.openframeworks.cc/index.php/topic,8729.0.html
gauthiier commented 2018-11-11 17:40:12 +01:00
Author
Owner
Copy Link

Author: @heavyside Posted at: 25.02.2012 15:41

Chris OShea's recommendations at Reply 13 here:

http://forum.openframeworks.cc/index.php/topic,8729.0.html

On 25 Feb 2012, at 15:40, jamie allen wrote:

we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing.

i don't think it's a memory bloat problem - the software doesn't freeze, it 'dies'. it's not slowing down, it's getting an error. and it doesn't consistently crash after 10 minutes - that's just the longest I've ever seen it run. it crashes sometimes right away, sometimes after 2 minutes, sometimes after 7 minutes. totally random timings, i think.

BTW - it does the same thing on OSX, just less frequently - if you let it run... it eventually crashes as well, probably for the same reason.

i'm fairly sure that the crashes are coming from the openframeworks saves not being thread safe and getting interrupted - so that the save can't finish, and it can't find "FIBITMAP from ofPixels". so this just happens sometimes - when there is an interrupt at the wrong time, randomly. this is the error on crash in Windows:

"unable to get FIBITMAP from ofPixels"

Tom is trying to integrate this today to see if it makes a difference - right Tom?
http://forum.openframeworks.cc/index.php?topic=1687.0

On 25 Feb 2012, at 15:22, dviid wrote:

the windows saving loop (in save_cb) shoot memory off the roof!

i've been profiling with OSX and memory keeps on shooting up - which could explain the "freeze" of the application after 10 minutes on windows.

unsigned char * somePixels;
ofPixels appPix = RefractiveIndex::_pixels;
somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3];
somePixels = appPix.getPixels();

ofImage myImage;
//myImage.allocate(appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR);

//his needs to be here for OSX of we get a BAD ACCESS ERROR. DOES IT BREAK WINDOWS? //
myImage.setUseTexture(false);

myImage.setFromPixels(somePixels,appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR);
myImage.saveImage(ofToDataPath("")+ _whole_file_path_analysis+"/"+file_name);

trying to fix this with "delete somePixels;" yet not conclusive...

Reply to this email directly or view it on GitHub:
https://github.com/gauthiier/RefractiveIndex/issues/7

Author: @heavyside Posted at: 25.02.2012 15:41 Chris OShea's recommendations at Reply 13 here: http://forum.openframeworks.cc/index.php/topic,8729.0.html On 25 Feb 2012, at 15:40, jamie allen wrote: > we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing. > > i don't think it's a memory bloat problem - the software doesn't freeze, it 'dies'. it's not slowing down, it's getting an error. and it doesn't consistently crash after 10 minutes - that's just the longest I've ever seen it run. it crashes sometimes right away, sometimes after 2 minutes, sometimes after 7 minutes. totally random timings, i think. > > BTW - it does the same thing on OSX, just less frequently - if you let it run... it eventually crashes as well, probably for the same reason. > > i'm fairly sure that the crashes are coming from the openframeworks saves not being thread safe and getting interrupted - so that the save can't finish, and it can't find "FIBITMAP from ofPixels". so this just happens sometimes - when there is an interrupt at the wrong time, randomly. this is the error on crash in Windows: > > "unable to get FIBITMAP from ofPixels" > > Tom is trying to integrate this today to see if it makes a difference - right Tom? > http://forum.openframeworks.cc/index.php?topic=1687.0 > > On 25 Feb 2012, at 15:22, dviid wrote: > > > the windows saving loop (in save_cb) shoot memory off the roof! > > > > i've been profiling with OSX and memory keeps on shooting up - which could explain the "freeze" of the application after 10 minutes on windows. > > > > unsigned char * somePixels; > > ofPixels appPix = RefractiveIndex::_pixels; > > somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; > > somePixels = appPix.getPixels(); > > > > ofImage myImage; > > //myImage.allocate(appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR); > > > > //his needs to be here for OSX of we get a BAD ACCESS ERROR. DOES IT BREAK WINDOWS? // > > myImage.setUseTexture(false); > > > > myImage.setFromPixels(somePixels,appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR); > > myImage.saveImage(ofToDataPath("")+ _whole_file_path_analysis+"/"+file_name); > > > > trying to fix this with "delete somePixels;" yet not conclusive... > > > > --- > > > > Reply to this email directly or view it on GitHub: > > https://github.com/gauthiier/RefractiveIndex/issues/7
gauthiier commented 2018-11-11 17:40:13 +01:00
Author
Owner
Copy Link

Author: @heavyside Posted at: 25.02.2012 15:41

we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing.

i don't think it's a memory bloat problem - the software doesn't freeze, it 'dies'. it's not slowing down, it's getting an error. and it doesn't consistently crash after 10 minutes - that's just the longest I've ever seen it run. it crashes sometimes right away, sometimes after 2 minutes, sometimes after 7 minutes. totally random timings, i think.

BTW - it does the same thing on OSX, just less frequently - if you let it run... it eventually crashes as well, probably for the same reason.

i'm fairly sure that the crashes are coming from the openframeworks saves not being thread safe and getting interrupted - so that the save can't finish, and it can't find "FIBITMAP from ofPixels". so this just happens sometimes - when there is an interrupt at the wrong time, randomly. this is the error on crash in Windows:

"unable to get FIBITMAP from ofPixels"

Tom is trying to integrate this today to see if it makes a difference - right Tom?
http://forum.openframeworks.cc/index.php?topic=1687.0

On 25 Feb 2012, at 15:22, dviid wrote:

the windows saving loop (in save_cb) shoot memory off the roof!

i've been profiling with OSX and memory keeps on shooting up - which could explain the "freeze" of the application after 10 minutes on windows.

unsigned char * somePixels;
ofPixels appPix = RefractiveIndex::_pixels;
somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3];
somePixels = appPix.getPixels();

ofImage myImage;
//myImage.allocate(appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR);

//his needs to be here for OSX of we get a BAD ACCESS ERROR. DOES IT BREAK WINDOWS? //
myImage.setUseTexture(false);

myImage.setFromPixels(somePixels,appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR);
myImage.saveImage(ofToDataPath("")+ _whole_file_path_analysis+"/"+file_name);

trying to fix this with "delete somePixels;" yet not conclusive...

Reply to this email directly or view it on GitHub:
https://github.com/gauthiier/RefractiveIndex/issues/7

Author: @heavyside Posted at: 25.02.2012 15:41 we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing. i don't think it's a memory bloat problem - the software doesn't freeze, it 'dies'. it's not slowing down, it's getting an error. and it doesn't consistently crash after 10 minutes - that's just the longest I've ever seen it run. it crashes sometimes right away, sometimes after 2 minutes, sometimes after 7 minutes. totally random timings, i think. BTW - it does the same thing on OSX, just less frequently - if you let it run... it eventually crashes as well, probably for the same reason. i'm fairly sure that the crashes are coming from the openframeworks saves not being thread safe and getting interrupted - so that the save can't finish, and it can't find "FIBITMAP from ofPixels". so this just happens sometimes - when there is an interrupt at the wrong time, randomly. this is the error on crash in Windows: "unable to get FIBITMAP from ofPixels" Tom is trying to integrate this today to see if it makes a difference - right Tom? http://forum.openframeworks.cc/index.php?topic=1687.0 On 25 Feb 2012, at 15:22, dviid wrote: > the windows saving loop (in save_cb) shoot memory off the roof! > > i've been profiling with OSX and memory keeps on shooting up - which could explain the "freeze" of the application after 10 minutes on windows. > > unsigned char * somePixels; > ofPixels appPix = RefractiveIndex::_pixels; > somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; > somePixels = appPix.getPixels(); > > ofImage myImage; > //myImage.allocate(appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR); > > //his needs to be here for OSX of we get a BAD ACCESS ERROR. DOES IT BREAK WINDOWS? // > myImage.setUseTexture(false); > > myImage.setFromPixels(somePixels,appPix.getWidth(),appPix.getHeight(), OF_IMAGE_COLOR); > myImage.saveImage(ofToDataPath("")+ _whole_file_path_analysis+"/"+file_name); > > trying to fix this with "delete somePixels;" yet not conclusive... > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/gauthiier/RefractiveIndex/issues/7
gauthiier commented 2018-11-11 17:40:13 +01:00
Author
Owner
Copy Link

Author: @tomschofield Posted at: 25.02.2012 16:12

"we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing."

that's correct Jamie - the ofImage is declared globally and memory allocated once in setup.

It does seem like that this is a threading issue. One thing that seems strange though is presumably the memory containing the pixels from the main app is accessed in "setFromPixels" rather than saveImage(). So you would expect the crash to happen here but that FITBITMAP error is generated in saveImage, AFTER this point.

Author: @tomschofield Posted at: 25.02.2012 16:12 "we've tried compiling on windows with the memory allocation outside of that part of the (I.e.: declared properly and allocate in setup), i believe - Tom? it's of course better to do it this way - but i don't think that's why it's crashing." that's correct Jamie - the ofImage is declared globally and memory allocated once in setup. It does seem like that this is a threading issue. One thing that seems strange though is presumably the memory containing the pixels from the main app is accessed in "setFromPixels" rather than saveImage(). So you would expect the crash to happen here but that FITBITMAP error is generated in saveImage, AFTER this point.
gauthiier commented 2018-11-11 17:40:14 +01:00
Author
Owner
Copy Link

Author: @tomschofield Posted at: 25.02.2012 17:24

just for kicks I tried using a threaded image saver (ofxThreadedImageSaver) (the rationale being that if one thread died, the whole app wouldn't). This worked for 25 minutes and then died with exactly the same FIBITMAP error proving that god likes to play games with us.

Author: @tomschofield Posted at: 25.02.2012 17:24 just for kicks I tried using a threaded image saver (ofxThreadedImageSaver) (the rationale being that if one thread died, the whole app wouldn't). This worked for 25 minutes and then died with exactly the same FIBITMAP error proving that god likes to play games with us.
gauthiier commented 2018-11-11 17:40:14 +01:00
Author
Owner
Copy Link

Author: @heavyside Posted at: 25.02.2012 19:06

is it crashing consistently at least? e.g.: running for the same amount of time each run?

On 25 Feb 2012, at 18:24, Tom Schofield wrote:

just for kicks I tried using a threaded image saver (ofxThreadedImageSaver) (the rationale being that if one thread died, the whole app wouldn't). This worked for 25 minutes and then died with exactly the same FIBITMAP error proving that god likes to play games with us.

Reply to this email directly or view it on GitHub:
https://github.com/gauthiier/RefractiveIndex/issues/7#issuecomment-4174363

Author: @heavyside Posted at: 25.02.2012 19:06 is it crashing consistently at least? e.g.: running for the same amount of time each run? On 25 Feb 2012, at 18:24, Tom Schofield wrote: > just for kicks I tried using a threaded image saver (ofxThreadedImageSaver) (the rationale being that if one thread died, the whole app wouldn't). This worked for 25 minutes and then died with exactly the same FIBITMAP error proving that god likes to play games with us. > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/gauthiier/RefractiveIndex/issues/7#issuecomment-4174363
gauthiier commented 2018-11-11 17:40:14 +01:00
Author
Owner
Copy Link

Author: @gauthiier Posted at: 25.02.2012 19:14

somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3];

is the line causing memory to bomb (which may or may not cause "windows the problem" - yet is one nevertheless - just look in Activity Monitor memory shooting up).

we don't need to malloc (new) space here since

somePixels = appPix.getPixels();

is basically changing the pointer from pointing to newly allocated unsigned char [appPix.getWidth()_appPix.getHeight()_3]; (which we never use) to appPix.getPixels();

commenting somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; fixes the problem

I don't have a windows install on my machine - will try to get one in the next few days trying to reproduce "windows problem".

threading could be a problem yet there is not obvious "concurrency" problem with our "save_cb".

We have only 2 main threads "OF/Draw" + "RF/Acquire/Synthesise/ShowResult". However each :

save_timer = new Timer(0, DELTA_T_SAVE) ---> save_cb

creates a thread - triggered each DELTA_T_SAVE interval (executing save_cb in its own thread). If the saveImage takes more time than DELTA_T_SAVE we may have a threading problem but through my debug session on OSX, I've never encountered such "concurrency" problem...

Author: @gauthiier Posted at: 25.02.2012 19:14 somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; is the line causing memory to bomb (which may or may not cause "windows the problem" - yet is one nevertheless - just look in Activity Monitor memory shooting up). we don't need to malloc (new) space here since somePixels = appPix.getPixels(); is basically changing the pointer from pointing to newly allocated unsigned char [appPix.getWidth()_appPix.getHeight()_3]; (which we never use) to appPix.getPixels(); commenting somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; fixes the problem --- I don't have a windows install on my machine - will try to get one in the next few days trying to reproduce "windows problem". threading could be a problem yet there is not obvious "concurrency" problem with our "save_cb". We have only 2 main threads "OF/Draw" + "RF/Acquire/Synthesise/ShowResult". However each : save_timer = new Timer(0, DELTA_T_SAVE) ---> save_cb creates a thread - triggered each DELTA_T_SAVE interval (executing save_cb in its own thread). If the saveImage takes more time than DELTA_T_SAVE we may have a threading problem but through my debug session on OSX, I've never encountered such "concurrency" problem...
gauthiier commented 2018-11-11 17:40:15 +01:00
Author
Owner
Copy Link

Author: @heavyside Posted at: 25.02.2012 19:21

yeah we should allocate the pixel memory properly, of course. Tom - does commenting somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3] break the Windows image saving or anything?

but the "windows problem" is not just on Windows - it's a general instability, i.e.: "crashing problem."
i'm seeing it on OSX - if you leave it running for over 10 minutes, for example, it will crash eventually... so something is unstable on both OSX and WINDOWS, longer term (i.e.: +10 mins)

does changing DELTA_T_SAVE to something like 1000 (i.e.: 1000 ms = 1 sec) make it more stable? Tom could you try this on Windows?

On 25 Feb 2012, at 20:14, dviid wrote:

somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3];

is the line causing memory to bomb (which may or may not cause "windows the problem" - yet is one nevertheless - just look in Activity Monitor memory shooting up).

we don't need to malloc (new) space here since

somePixels = appPix.getPixels();

is basically changing the pointer from pointing to newly allocated unsigned char [appPix.getWidth()_appPix.getHeight()_3]; (which we never use) to appPix.getPixels();

commenting somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; fixes the problem

I don't have a windows install on my machine - will try to get one in the next few days trying to reproduce "windows problem".

threading could be a problem yet there is not obvious "concurrency" problem with our "save_cb".

We have only 2 main threads "OF/Draw" + "RF/Acquire/Synthesise/ShowResult". However each :

save_timer = new Timer(0, DELTA_T_SAVE) ---> save_cb

creates a thread - triggered each DELTA_T_SAVE interval (executing save_cb in its own thread). If the saveImage takes more time than DELTA_T_SAVE we may have a threading problem but through my debug session on OSX, I've never encountered such "concurrency" problem...

Reply to this email directly or view it on GitHub:
https://github.com/gauthiier/RefractiveIndex/issues/7#issuecomment-4175310

Author: @heavyside Posted at: 25.02.2012 19:21 yeah we should allocate the pixel memory properly, of course. Tom - does commenting somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3] break the Windows image saving or anything? but the "windows problem" is not just on Windows - it's a general instability, i.e.: "crashing problem." i'm seeing it on OSX - if you leave it running for over 10 minutes, for example, it will crash eventually... so something is unstable on both OSX and WINDOWS, longer term (i.e.: +10 mins) does changing DELTA_T_SAVE to something like 1000 (i.e.: 1000 ms = 1 sec) make it more stable? Tom could you try this on Windows? On 25 Feb 2012, at 20:14, dviid wrote: > somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; > > is the line causing memory to bomb (which may or may not cause "windows the problem" - yet is one nevertheless - just look in Activity Monitor memory shooting up). > > we don't need to malloc (new) space here since > > somePixels = appPix.getPixels(); > > is basically changing the pointer from pointing to newly allocated unsigned char [appPix.getWidth()_appPix.getHeight()_3]; (which we never use) to appPix.getPixels(); > > commenting somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; fixes the problem > > --- > > I don't have a windows install on my machine - will try to get one in the next few days trying to reproduce "windows problem". > > threading could be a problem yet there is not obvious "concurrency" problem with our "save_cb". > > We have only 2 main threads "OF/Draw" + "RF/Acquire/Synthesise/ShowResult". However each : > > save_timer = new Timer(0, DELTA_T_SAVE) ---> save_cb > > creates a thread - triggered each DELTA_T_SAVE interval (executing save_cb in its own thread). If the saveImage takes more time than DELTA_T_SAVE we may have a threading problem but through my debug session on OSX, I've never encountered such "concurrency" problem... > > --- > > Reply to this email directly or view it on GitHub: > https://github.com/gauthiier/RefractiveIndex/issues/7#issuecomment-4175310
gauthiier commented 2018-11-11 17:40:15 +01:00
Author
Owner
Copy Link

Author: @gauthiier Posted at: 25.02.2012 19:28

i'm stress testing now... ô bugs please enter my debugger

Author: @gauthiier Posted at: 25.02.2012 19:28 i'm stress testing now... ô bugs please enter my debugger
gauthiier commented 2018-11-11 17:40:15 +01:00
Author
Owner
Copy Link

Author: @gauthiier Posted at: 25.02.2012 20:37

ok got DELTA_T_SAVE = 1 ms

somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3];

ran the program until memory gets at 1.12 G which generated:

ofImage::getBmpFromPixels() unable to get FIBITMAP from ofPixels

and a bunch of malloc: *** mmap(size=921600) failed (error code=12)

which means that the OS (X here) is blocking the app from bloating up the memory causing freeimage (and its malloc) to fail.

I'm now running the app without the somePixels allocation, trying to reproduce.

Author: @gauthiier Posted at: 25.02.2012 20:37 ok got DELTA_T_SAVE = 1 ms - somePixels = new unsigned char [appPix.getWidth()_appPix.getHeight()_3]; ran the program until memory gets at 1.12 G which generated: ofImage::getBmpFromPixels() unable to get FIBITMAP from ofPixels and a bunch of malloc: *** mmap(size=921600) failed (error code=12) which means that the OS (X here) is blocking the app from bloating up the memory causing freeimage (and its malloc) to fail. I'm now running the app without the somePixels allocation, trying to reproduce.
gauthiier commented 2018-11-11 17:40:16 +01:00
Author
Owner
Copy Link

Author: @gauthiier Posted at: 25.02.2012 21:18

ran the app for 30 mins - without the error... memory stabilises at 64 MB

Jamie: I'll try to get the error tomorrow on your Wondiws machine!

Author: @gauthiier Posted at: 25.02.2012 21:18 ran the app for 30 mins - without the error... memory stabilises at 64 MB Jamie: I'll try to get the error tomorrow on your Wondiws machine!
gauthiier commented 2018-11-11 17:40:16 +01:00
Author
Owner
Copy Link

Author: @heavyside Posted at: 01.03.2012 18:57

looks like we finally cracked the crashing problem, which was different than the writing black frames issue... it was basically this problem crashing windows...:
http://forum.openframeworks.cc/index.php?topic=1867.0

so we plopped in a bunch of image.clear(); statements and it seems pretty stable.

Author: @heavyside Posted at: 01.03.2012 18:57 looks like we finally cracked the crashing problem, which was different than the writing black frames issue... it was basically this problem crashing windows...: http://forum.openframeworks.cc/index.php?topic=1867.0 so we plopped in a bunch of image.clear(); statements and it seems pretty stable.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
No items
No Label
Milestone
No items
No Milestone
Assignees
Clear assignees
gauthiier
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Reference: gauthiier/RefractiveIndex#7
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?