CreeperMario
commented
7 years ago This seems to work as well, but I'm still not sure if this is the proper fix.
static int __libwut_lock_acquire(int *lock)
{
OSMutex *mutex = NULL;
if (!lock || *lock == 0) {
return -1;
}
+ mutex = (OSMutex*)*lock;
OSLockMutex(mutex);
return 0;
}
static int __libwut_lock_release(int *lock)
{
OSMutex *mutex = NULL;
if (!lock || *lock == 0) {
return -1;
}
+ mutex = (OSMutex*)*lock;
OSUnlockMutex(mutex);
return 0;
}
exjam
Hi. So I finally found a bug caused by newlib, which I discovered while working on porting @shinyquagsire23's Pazaak game to CMake WUT.
So basically, any attempts to call
fopen()will result in a freeze. Following the stack dump retrieved from dumping my console's crash logs (pulled using Mocha CFW and FTPiiU Everywhere, from/storage_slc/logs), the issue is definitely caused by attempting to create a mutex.At the top of the stack (or bottom?) is the function
__libwut_lock_acquire, which as you know is fromnewlib.cin libcrt.I'm not too experienced with threading and stuff like that, but I really don't think a mutex would exist at 0x0 (NULL). Is this
mutexvariable supposed to be initialized to something? Or are we supposed to uselockorsMallocMutexinstead?I tried stubbing
__libwut_lock_acquire(and__libwut_lock_release) to simply return 0 and not do anything else, and this allowsfopenand all related routines to work flawlessly, however not doing anything with this mutex is probably not the best thing to do in multithreded environments.