I have restarted work on my PNGview add-in, and after finally making it display PNGs correctly, now it also supports JPEG.

It doesn't work right with images much larger than 7KB because of two things: one, the default heap size for the add-ins isn't very big (and the PNG decoder requires lots of RAM), and second, it doesn't seem to 'free' all the memory it 'malloc's, even though I can't see where in the code the memory leak is exactly.

The PNG decoder may fail after decoding the same image many times: it displays a nice message with a LodePNG error code. The JPEG decoder fails more often, and in a less soft way: it causes a system error, caused by a TLB error. I don't see how the JPEG decoder can be accessing memory where it shouldn't, except for one thing: as it reads the file (it's configured for reading 1024 bytes at a time), it grows in the heap and at some point exceeds it.
I'd like to confirm this and how to fix it, but I don't know how...

There's a README file in the package which says more or less the same as what I wrote here. I don't provide any G3A or any sort of binary, and it'll probably be this way even on the release versions (because of the points expressed on the original PNGview thread). It's your responsibility to compile and run the code.
I recommend you read the messages in the About screens (press F6 after starting the compiled add-in, or read them in the source code). It explicitly says I take no responsibility for anything less appropriate people may do with this add-in.

Source code for development build number 52 of Image Viewer:
http://tny.im/dl/casioprizm/ImageViewer.zip

Help me debug, please! Smile
first comment Very Happy

I'll try to compile/test tomorrow
Bump...

Pretty pretty please, can someone help me with memory cleanup? I'm sure there's something that keeps using memory and isn't freed, because if I keep on loading a JPG file it'll system error at some point, or if I jump between decoding PNGs and JPGs.

Else, is there a way to increase the heap so that these leak issues are less noticeable (not that that's a permanent fix, however)?
Perhaps just use a large portion of the stack for memory, and manually keep track of the contents yourself? The size of the stack is (at least, I'm not sure if we've discovered it to be larger) 512KB, which is much more than the heap can provide. Unless the latest rendition of the PrizmSDK changed it, you'll have to modify your Prizm.ld file to allow for a 512K stack. Then,


Code:
static char space[500000];


Should provide you with 500KB to work with. It's a good idea to leave that extra 12KB for all other variables and return addresses to safely have more than enough room to work.
That goes in the .data segment, not the stack (though they appear to be mapped to the same portion of memory). As long as you don't depend on it being zeroed out (which is a runtime environment guarantee for static variables), startup will be faster if you actually allocate it on the stack.

Code:
#define CLAIM_SIZE (1 << 18)
void *space;
int main() {
#ifdef USE_ALLOCA
    space = alloca(CLAIM_SIZE);
#else
    char _space[CLAIM_SIZE];
    space = &_space;
#endif
    // Do things
}

We've discussed this before in some other thread, and I mentioned that I'd like to add a feature like this to libfxcg, so addon programmers don't need to deal with the details. You can write a malloc wrapper to manage your reserved chunk of memory, or just use it as a huge buffer depending on your needs.
Well, I tried to use custom memory allocation functions that allocated a huge array (256KB) when the add-in started, and then managed that using custom functions that I used in place of malloc, free and friends.
(I think this is the solution Ashbad suggested. If it is, it doesn't work well, see: )
With 256KB though, it errors much sooner than by using native malloc, and if I specify the array to be 500KB, it'll just error once I try to custom-malloc something.

I'll try using Tari's code with alloca and report back.
EDIT: oh wait. there's no alloca in libfxcg. For some reason I didn't use it before Sad

EDIT2: Also, I think the problem with JPG isn't clearly the lack of memory, because the library I'm using (TJpgDec) was made for embedded systems and shouldn't use more than 3 KB of RAM no matter what the file size. Still, the JPG viewer returns an error sooner or later (using the native memory management functions), and this without using the PNG viewer at all.
gbl08ma wrote:
I'll try using Tari's code with alloca and report back.
EDIT: oh wait. there's no alloca in libfxcg. For some reason I didn't use it before Sad

Code:
#include <alloca.h>
It's a compiler builtin.

Sounds like there's a bug in your jpeg library to me. Is valgrind on your PC an option for debugging?
Tari wrote:
gbl08ma wrote:
I'll try using Tari's code with alloca and report back.
EDIT: oh wait. there's no alloca in libfxcg. For some reason I didn't use it before Sad

Code:
#include <alloca.h>
It's a compiler builtin.

Sounds like there's a bug in your jpeg library to me. Is valgrind on your PC an option for debugging?
That's what I said on IRC. Smile I suggested he pull out the decoder, compile it on computer, and then run it to segfault/failure with GDB or Valgrind it for leaks.
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
Page 1 of 1
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement