--- Log opened Tue Nov 29 00:02:29 2011
00:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has joined #freemyipod
00:02 -!- clustur [~logger@c-98-249-104-118.hsd1.tn.comcast.net] has quit [Remote host closed the connection]
00:24 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Read error: Connection timed out]
00:34 -!- Keripo [~Keripo@eng415.wireless-resnet.upenn.edu] has quit [Ping timeout: 260 seconds]
03:25 -!- TheSeven [~TheSeven@rockbox/developer/TheSeven] has quit [Disconnected by services]
03:26 -!- [7] [~TheSeven@rockbox/developer/TheSeven] has joined #freemyipod
08:28 -!- Liath [~Liath@fctnnbsc30w-198164219007.dhcp-dynamic.FibreOp.nb.bellaliant.net] has quit [Ping timeout: 258 seconds]
08:42 -!- Liath [~Liath@fctnnbsc30w-198164211239.dhcp-dynamic.FibreOp.nb.bellaliant.net] has joined #freemyipod
11:46 -!- soap is now known as soap_
11:55 -!- ShapeShifter499 [~ShapeShif@c-98-244-33-205.hsd1.ca.comcast.net] has joined #freemyipod
12:35 -!- ShapeShifter499 [~ShapeShif@c-98-244-33-205.hsd1.ca.comcast.net] has quit [Quit: Leaving]
14:30 -!- Utchybann [~Utchy@rps6752.ovh.net] has quit [*.net *.split]
14:30 -!- Poodlemastah [~Poodlemas@h-241-205.a218.priv.bahnhof.se] has quit [*.net *.split]
14:36 -!- Utchybann [~Utchy@rps6752.ovh.net] has joined #freemyipod
14:36 -!- Poodlemastah [~Poodlemas@h-241-205.a218.priv.bahnhof.se] has joined #freemyipod
16:49 -!- n1s [~n1s@rockbox/developer/n1s] has joined #freemyipod
16:56 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has joined #freemyipod
18:12 -!- Keripo [~Keripo@SEAS297.wlan.seas.upenn.edu] has joined #freemyipod
18:52 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod
19:05 < [7]> http://pastie.org/2905488 - ideas?
19:43 -!- Keripo1 [~Keripo@SEAS297.wlan.seas.upenn.edu] has joined #freemyipod
19:46 -!- Keripo [~Keripo@SEAS297.wlan.seas.upenn.edu] has quit [Ping timeout: 244 seconds]
19:53 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Read error: Connection reset by peer]
19:54 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod
19:57 -!- Keripo1 [~Keripo@SEAS297.wlan.seas.upenn.edu] has quit [Quit: Leaving.]
20:24 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Ping timeout: 258 seconds]
20:28 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has joined #freemyipod
20:40 < [7]> http://pastie.org/2940564 << evil
21:25 < user890104> [7]: can you start stripping down some parts of the bootmenu, until it doesn't cause memory corruption anymore?
21:25 < user890104> or you already tried it
21:36 -!- benedikt93 [~benedikt9@unaffiliated/benedikt93] has quit [Quit: Bye ;)]
21:49 < [7]> this seems to be related to the location of some buffers and the order in which they are freed
21:59 < [7]> more exactly, it looks like tlsf_free sometimes forgets to update a couple of pointers
22:01 < user890104> did you test that with just allocating/freeing ranges of memory with emcore.py? i mean without running the bootmenu at all?
22:01 < [7]> no, but it only seems to happen in some certain situations
22:03 < [7]> [start of malloc space] [allocation1] [free space] [allocation 2] [free space] [end of malloc space] seems to be such a case
22:03 < [7]> when allocation1 is freed, the free list pointers of the free space chunk being extended apparently aren't moved to its new base address
22:04 < user890104> what about making tlsf_free more verbose?
22:06 < user890104> or maybe block_merge_[prev|next]
22:06 -!- liar [~liar@clnet-p09-185.ikbnet.co.at] has quit [Remote host closed the connection]
22:10 < [7]> that's what my next step will be
22:12 < user890104> i see
22:19 < [7]> libc/tlsf/tlsf.c:425: insert_free_block(0x08000000, 0x08000C60, 10, 15)
22:19 < [7]> libc/tlsf/tlsf.c:427: insert_free_block: old head: 0BFFC224
22:19 < [7]> libc/tlsf/tlsf.c:430: insert_free_block: [08000C68]: 08000C68 => 0BFFC224
22:19 < [7]> libc/tlsf/tlsf.c:432: insert_free_block: [08000C6C]: 2000001F => 0BFFC224
22:19 < [7]> libc/tlsf/tlsf.c:434: insert_free_block: [0BFFC230]: 0BFFC224 => 08000C60
22:19 < [7]> the last 3 lines are [addr]: old value => new value when updating the list
22:20 < [7]> so that looks good. it's just a bit weird that the old values seem to survive nevertheless...
22:20 < [7]> code for that:
22:20 < [7]>     DEBUGF("insert_free_block: [%08X]: %08X => %08X", &(block->next_free), block->next_free, current);
22:20 < [7]> 	block->next_free = current;
22:20 < [7]>     DEBUGF("insert_free_block: [%08X]: %08X => %08X", &(block->prev_free), block->prev_free, &block_null);
22:20 < [7]> 	block->prev_free = &block_null;
22:20 < [7]>     DEBUGF("insert_free_block: [%08X]: %08X => %08X", &(current->prev_free), current->prev_free, block);
22:20 < [7]> 	current->prev_free = block;
22:20 < [7]> how can that fail?
22:27 < [7]> arrrrrr
22:27 < [7]> i think I know what's going on
22:27 < [7]> damn race conditions
22:46 < [7]> fixed :)
22:46 < user890104> \o/
22:48 -!- n1s [~n1s@rockbox/developer/n1s] has quit [Quit: Ex-Chat]
22:49 < fmibot> New commit by theseven (r818): emCORE: Fix a really nasty memory corruption bug that was triggered by deallocating thread handles that didn't have free space in front of them during the deallocation.
22:50 < [7]> guess what happened :)
22:50 < fmibot> r818 build result: emcore: Red for targets ipodnano2g, ipodnano3g, ipodnano4g, ipodclassic, ipodtouch2g (theseven commited)
22:50 < [7]> arrrr
22:50 < fmibot> r818 build result: umsboot: All green!
22:51 < fmibot> New commit by theseven (r819): Fix red, forgot to commit that...
22:51 < fmibot> r819 build result: emcore: All green!
22:51 < fmibot> r819 build result: umsboot: All green!
22:52 < [7]> so that one is finally gone as well...
22:52 < [7]> which means that I can focus on the libui and bootmenu changes tomorrow :)
22:54 < user890104> and i can complete my file browser/launcher app
22:55 < [7]> if you have spare time, you might want to look at my change and try to figure out what actually happened, i.e. how this did cause tlsf free chain corruption
22:56 < user890104> well, i'll need to understand how the tlsf stuff works first
22:56 < [7]> tlsf itself is completely unrelated here
22:57 < [7]> it just suffered from someone trashing its linked lists
23:00 < user890104> so it was caused by the multithreading?
--- Log closed Wed Nov 30 00:02:27 2011