[KOS] Thread, png_to_texture and pre-magic is wrong

[patbier]

Hello,

I'm trying to use threads to load my textures, so that I can display an animation during loading.

But I have a warning when the thread is exiting, and I'd like to know your opinion.
I'm using the last KOS SVN version (Rev 606)

Here is the example :

1) In the function which launches the thread :

Code: Select all

...
kthread_t * process_loading;
process_loading=thd_create(loadTextures,0);
thd_wait(process_loading);
...

2) The thread function :

Code: Select all

void loadTextures() {  
  newText[0] = pvr_mem_malloc(512*512*2);
  png_to_texture("/cd/newText.png", newText[0], PNG_FULL_ALPHA);
  thd_exit();
}

When the thread is exiting (thd_exit), I have some warnings :

Code: Select all

Thread 4/8c08bf52 freeing block @ 8c162aa8
  pre-magic is wrong at index 26 (6677656e)
Thread 4/8c08bf52 freeing block @ 8c162aa8
  pre-magic is wrong at index 27 (2e646e6f)
Thread 4/8c08bf52 freeing block @ 8c162aa8
  pre-magic is wrong at index 28 (00636f70)
Thread 4/8c08bf52 freeing block @ 8c162aa8
  pre-magic is wrong at index 29 (67006300)
  DAMAGED BLOCK DURING FREE

But it works, and the texture is correct when I display it.
Do you have any ideas to help me ? Do someone has already seen these warnings ? Are these warnings annoying, namely can I have a crash after different loadings ? Is the function png_to_texture not thread-friendly ?

Thanks for your help !

[Quzar]

I'm not sure as to if it's thread safe, but a way to test if png_to_texture is safe would be to remove the png conversion process. Convert the png to a texture and load it directly (I think KMG is made for that but I may be wrong) outside of the thread.

[BlackAura]

Actually, that looks like it's coming from the memory allocator, rather than the PNG library or threading system.

(looks at the code)

Yep. That message comes from libc/stdlib/malloc.c. Basically, the memory allocator sticks a known number before each allocated memory block, and checks it when the block is freed. It looks like something's overwritten this number on one or more blocks, so the memory allocator is warning you about it.

It probably means there's a buffer overflow (or underflow) somewhere in there, which is clobbering the contents of adjacent memory blocks. It could be harmless, but it could also cause all kinds of hard-to-find bugs.

It's not taking out all of the padding though, so this doesn't appear to be causing any damage. However, if you were to disable this debugging code (it actually increases memory usage by 50%), it'd almost certainly cause damage, and make things break unpredictably.

That doesn't help narrow it down though. It could be anywhere in the threading system, the filesystem, the PNG library, or the KOS PNG loader. It could also be caused by a thread safely problem in any of those components, but that's not too likely if you only have one thread trying to use the PNG loader. I'm pretty sure the filesystem is thread-safe, but I don't know if the memory allocator is.

[patbier]

Thanks for your answers.

I have found another bug in my game which causes a freeze in a particular action. So I suspect a buffer overflow somewhere in my code.
As you suggest BlackAura, this can be the source of the "DAMAGED BLOCK DURING FREE" problem too.

Indeed, I asked the question here because I'd like to know if someone has already seen the "DAMAGED BLOCK DURING FREE" warning, or if someone use threads for loading textures without any warnings / errors.

I try to use gdb / insight to debug my program. It works with my bba, using the dc-tool instruction, but when my program freezes, insight can't say where it stops... That is the very bad part of the programmation : the "hard-to-find bugs" like you said BlackAura...

[BlueCrab]

The memory allocator should be just fine with threading, as it takes care of thread-protection on its own. The filesystem isn't thread-safe, but it doesn't do any memory allocation that I can recall off the top of my head, so I somewhat doubt it is causing your issue.

The PNG library itself should be thread-safe, but the version in KOS is rather old, so its possible that its not for some reason. Its doubtful though. The KOS PNG loader (from a quick browse of the code) doesn't seem to do anything that would cause your issue either.

Most likely its a bug in your code somewhere (but if you happen to find it is in KOS somewhere, let me know, and I'll try to fix it up for you).