--- Log for 28.03.120 Server: cherryh.freenode.net Channel: #rockbox --- Nick: logbot Version: Dancer V4.16 Started: 21 days and 10 hours ago 00.07.35 Quit sakax (Quit: Leaving) 00.16.38 Join mendelmunkis [0] (~mendelmun@65-128-208-151.mpls.qwest.net) 00.41.12 Join Soap [0] (~Soap@rockbox/staff/soap) 00.41.53 Quit Rower (Quit: Hmmm...) 00.45.19 Join Rower [0] (~husvagn@m83-191-113-108.cust.tele2.se) 00.49.46 Quit Rower (Ping timeout: 256 seconds) 01.10.07 Quit petur (Quit: Leaving) 01.19.43 *** Saving seen data "./dancer.seen" 01.39.00 # bluebrother, when you get a chance, I'd like you to repeat that mini2g test with the latest nightly build (if it wasn't already the case) just so we can be sure it was my build that broke. 01.39.39 # and as a secondary test, blow away the .rockbox dir altogether so only the new build's files are present. 01.42.17 Quit cockroach (Quit: leaving) 01.44.53 Quit krabador (Quit: Leaving) 01.51.17 Quit MrZeus (Read error: Connection reset by peer) 01.54.12 Join Nuggettet [0] (4574c419@ool-4574c419.dyn.optonline.net) 01.55.06 # Hey how do I navigate between two firmwares on an ipod? 01.56.37 # Another time I navigated ti Apple firmware but wasnt able to go back to rockbox. 01.57.33 # <__builtin> depending on which model the bootloader listens for a certain key combination 01.57.49 # <__builtin> with ipod6gboot you press SELECT to boot rockbox 01.58.28 # ah I see 01.58.55 # Would it be safe to just get rid of the apple firmware all together? 02.00.54 # I'll have my data backed up regardless? 02.04.16 Join MrZeus [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net) 02.14.12 # <__builtin> I think so, yes 02.26.18 # How do 02.27.02 # I get rid of the apple firmware permanently without having to connect the ipod and the apple firmware comes back? 02.52.39 # ? 03.12.18 # * __builtin doesn't remember 03.15.43 # <__builtin> I'd check the wiki 03.19.46 *** Saving seen data "./dancer.seen" 03.21.24 # <__builtin> speachy: quake also freezes on exit with 4.9.4, but not 4.4.4 03.26.27 # ok thnx 03.26.31 Quit Nuggettet (Remote host closed the connection) 04.24.49 Quit _3dsv (Ping timeout: 264 seconds) 04.25.46 Join _3dsv [0] (~3dsv@97-91-206-90.dhcp.stls.mo.charter.com) 04.27.09 Join lodzie [0] (7a38c813@122-56-200-19.mobile.spark.co.nz) 04.27.14 # hey guys 04.27.16 # problem 04.27.21 # tryna convert an avi 04.27.25 # with winff 04.27.43 # gives me an error about b frames and wants me to use virtualdub or avidemux to fix it 04.27.52 # idk how to use any of them 04.27.57 # can someone plz help me? 04.35.31 # anyone here can help? 04.43.54 Join Rower [0] (~husvagn@m83-191-113-108.cust.tele2.se) 04.50.53 Quit Rower (Ping timeout: 240 seconds) 04.53.48 Quit lodzie (Remote host closed the connection) 05.19.48 *** Saving seen data "./dancer.seen" 05.23.23 Join Strife89-Treo [0] (~upirc@adsl-74-250-141-84.ags.bellsouth.net) 05.25.05 Quit Strife89-Treo (Remote host closed the connection) 06.27.41 Nick JanC is now known as Guest71318 (~janc@lugwv/member/JanC) 06.27.41 Quit Guest71318 (Killed (livingstone.freenode.net (Nickname regained by services))) 06.27.42 Join JanC [0] (~janc@lugwv/member/JanC) 06.41.24 Quit ac_laptop (Ping timeout: 250 seconds) 07.07.21 Quit MrZeus (Ping timeout: 256 seconds) 07.19.51 *** Saving seen data "./dancer.seen" 09.17.58 Join Rower [0] (~husvagn@m83-191-113-108.cust.tele2.se) 09.19.55 *** No seen item changed, no save performed. 09.34.55 Join prof_wolfff [0] (~prof_wolf@37.120.204.156) 10.02.06 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr) 10.35.54 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 10.41.26 Join massiveH [0] (~massiveH@ool-18e4eaeb.dyn.optonline.net) 11.02.19 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 11.06.10 Quit prof_wolfff (Ping timeout: 250 seconds) 11.10.51 Quit pixelma (Quit: .) 11.10.51 Quit amiconn (Quit: http://quassel-irc.org - Chat comfortably. Anywhere.) 11.11.05 Join amiconn [0] (jens@rockbox/developer/amiconn) 11.11.06 Join pixelma [0] (marianne@rockbox/staff/pixelma) 11.19.58 *** Saving seen data "./dancer.seen" 11.43.40 # Build Server message: New build round started. Revision 022dfe7, 281 builds, 11 clients. 12.02.10 # Build Server message: Build round completed after 1110 seconds. 12.02.11 # Build Server message: Revision 022dfe7 result: All green 12.15.09 Quit massiveH (Quit: Leaving) 12.32.30 # __builtin, is that on the ipod6g? 12.33.53 Quit lebellium (Quit: Leaving) 12.36.41 Join lebellium [0] (~lebellium@89-92-253-148.hfc.dyn.abo.bbox.fr) 12.43.36 # speachy: tried e200. Current git head: fine with gcc 4.4.4. Crashes during boot with 4.9.9 12.43.41 # *4.9.4 12.44.11 # Data abort at 0008b310 (0) 12.44.31 # pc:0008b310 sp:000f5a28 12.45.47 # so the mini2g and e200 have one notable thing in common -- they're both arm7tdmi targets 12.46.01 # the clip+ and ipod6g are arm926ejs 12.46.57 # according to the map file this is in queue.o 12.47.10 # at least the e200 shows me something :) 12.47.20 # .text 0x000000000008b300 0xafc /home/dom/projects/rockbox/build-e200-gcc494/firmware/libfirmware.a(queue.o) 0x000000000008b384 queue_enable_queue_send 12.52.08 # okay, try this. 12.52.28 # in the configure script, get rid of '-funit-at-a-time' in CCOPTS near the very top 12.52.36 # then 'make reconf && make zip' 12.53.32 # compiler could be optimizing something away thanks to that. 12.54.28 # too bad we don't know the address that tripped the abort.. 12.54.50 # question is, is this an unaligned access or a pointer into neverland? 12.58.04 # (or an attempt to write to a read-only location..) 13.03.48 # when I did a build, that address is in queue_release_sender_innner() 13.07.08 # corresponding to line 73 of firmware/kernel/queue.c 13.20.01 *** Saving seen data "./dancer.seen" 13.50.34 Join prof_wolfff [0] (~prof_wolf@195.158.248.20) 13.58.19 # speachy: same result. Both on e200 and mini2g 13.59.17 # hmm. queue_release_sender_inner() doesn't appear in my map file? 14.08.23 Quit prof_wolfff (Ping timeout: 256 seconds) 14.08.45 # mroe reliable than the map is the obdjump -d output 14.12.44 # good point :) 14.23.13 Join prof_wolfff [0] (~prof_wolf@84.17.62.195) 14.28.46 Quit prof_wolfff (Ping timeout: 256 seconds) 14.58.16 Join krabador [0] (~krabador@unaffiliated/krabador) 15.18.31 Quit krabador (Remote host closed the connection) 15.20.02 *** Saving seen data "./dancer.seen" 15.22.25 Join krabador [0] (~krabador@unaffiliated/krabador) 15.33.31 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 15.37.47 Quit sakax (Quit: Leaving) 15.50.06 Join prof_wolfff [0] (~prof_wolf@84.17.62.195) 15.59.08 Nick TheSilentLink_ is now known as TheSilentLink (~TheSilent@unaffiliated/thesilentlink) 16.05.06 Quit pamaury (Ping timeout: 256 seconds) 16.11.28 Join pamaury [0] (~pamaury@rockbox/developer/pamaury) 16.17.03 Quit brasello (Quit: leaving) 16.17.41 Join brasello [0] (~brasello@anon-39-6.vpn.ipredator.se) 16.31.47 Join _Bilgus [0] (~Bilgus@unaffiliated/bilgus) 16.32.33 Quit Bilgus (Ping timeout: 240 seconds) 17.03.00 # <__builtin> speachy: yes 17.03.19 # <__builtin> Seems to be intermittent 17.04.13 Join TheLemonMan [0] (~lemonboy@irssi/staff/TheLemonMan) 17.06.16 Quit michaelni (Ping timeout: 250 seconds) 17.06.28 # <__builtin> I'll make sure to investigate more 17.19.37 Join michaelni [0] (~michael@213-47-68-29.cable.dynamic.surfer.at) 17.20.04 *** Saving seen data "./dancer.seen" 17.30.59 Quit Rower (Quit: Hmmm...) 17.35.03 Quit prof_wolfff (Ping timeout: 256 seconds) 18.39.20 Join cockroach [0] (~blattodea@pdpc/supporter/active/cockroach) 19.20.06 *** Saving seen data "./dancer.seen" 19.27.40 Quit TheLemonMan (Ping timeout: 265 seconds) 19.42.05 Join Rower [0] (~husvagn@m83-191-113-108.cust.tele2.se) 19.47.35 Join MrZeus [0] (~MrZeus@79-65-237-109.host.pobb.as13285.net) 20.11.31 # <__builtin> ok, building toolchains 20.18.09 Quit Moarc (Quit: i znowu NADMUCHAŁ BALONA) 20.20.07 Join Moarc [0] (~chujko@a105.net128.okay.pl) 20.21.12 Quit ac_laptop (Ping timeout: 240 seconds) 20.22.29 Join reductum [0] (~weechat@cpe-104-175-169-123.socal.res.rr.com) 20.25.18 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 20.30.06 Join prof_wolfff [0] (~prof_wolf@84.17.62.195) 20.35.39 Quit reductum (Quit: WeeChat 2.7.1) 20.35.59 Join reductum [0] (~weechat@cpe-104-175-169-123.socal.res.rr.com) 20.38.23 # <__builtin> ok, this quake crash is odd 20.38.35 Quit ac_laptop (Ping timeout: 250 seconds) 20.38.56 # <__builtin> taking place at PC=0x82cc, which isn't code 20.40.26 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 20.46.31 Quit ac_laptop (Ping timeout: 256 seconds) 20.56.43 Join sakax [0] (~r0b0t@unaffiliated/r0b0t) 21.08.23 # * speachy should have done those toolchains with a different prefix 21.12.58 # <__builtin> I've traced the quake crash down to corruption of a pointer 21.13.33 # <__builtin> some pointer to a mutex is getting overwritten with 0x20, which is causing subsequent stuff to fail 21.14.52 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 21.15.53 # <__builtin> oh, great... adding instrumentation code causes the crash to go away 21.20.07 *** Saving seen data "./dancer.seen" 21.39.26 Quit pamaury (Ping timeout: 256 seconds) 21.54.44 # gotta love schrodinger's bugs 22.04.08 Join Soap_ [0] (~Soap@rockbox/staff/soap) 22.06.04 Quit ac_laptop (Ping timeout: 256 seconds) 22.06.47 Quit reductum (Quit: WeeChat 2.7.1) 22.07.12 Quit Soap (Ping timeout: 256 seconds) 22.07.22 Join Soap [0] (~Soap@rockbox/staff/soap) 22.10.04 Quit Soap_ (Ping timeout: 265 seconds) 22.12.25 # <__builtin> hmm... gcc has a nice way to automaticall instrument functions 22.22.44 # <__builtin> though given my luck I can almost guarantee that the bug goes away then, too 22.23.53 # if a bug goes away "by itself", it will always come back later 22.28.12 # <__builtin> the hard part is getting it to come back when you want it to :) 22.31.56 # <__builtin> no surprise... it goes away with instrumentation 22.45.10 # <__builtin> it seems like some unrelated code is stepping on this code's memory 22.54.39 # Very strange. 22.55.08 # Wonder if there's an ascii buffer overrun somewhere. I assume that mutex etc is in the heap, rather than statically allocated? 22.55.37 # the crash on the arm7tdmi targets was in the queueing code, which also involves mutexes. 23.00.33 Quit prof_wolfff (Ping timeout: 258 seconds) 23.02.45 # <__builtin> it's in the ported SDL 23.03.24 # <__builtin> the pointer itself is statically allocated 23.03.29 # <__builtin> and that's what's being stepped on 23.04.14 # <__builtin> what I want is to set a watchpoint on the pointer so I can figure out what's writing to it... but alas 23.04.29 # Another common trick is to enable higher optimization levels, that makes GCC do a lot more analysis. 23.05.31 # <__builtin> how would that help? 23.05.59 # more analysis often leads to more warnings 23.06.08 # about unsafe code, that is 23.06.33 # but alas, doesn't seem to be helping here. 23.06.59 # <__builtin> problem is, SDL already spews out loads of warnings 23.08.11 # ah, I see SDL is already built with -O3 23.09.01 # <__builtin> the problem is in sdl/src/thread/SDL_thread.c 23.09.03 # and with warnings disables 23.09.15 # <__builtin> yeah... hehe :) 23.11.36 # lots of more problematic warnings underneath all of the noise 23.12.14 # <__builtin> I suppose I can try filtering out the noise 23.12.29 # when you run some typical desktop apps from the command line, I'm surprised by the amount of "asserts" that go off but are apparently all ignored/left in 23.13.15 # an assert is basically a critical precondition for some part of the software that's supposed to always be true 23.14.06 # but in practice a lot of these checks are not satisfied in linux desktop software 23.14.48 # either the check is wrong, or the code is wrong, both are highly questionable 23.15.08 # but that's no rockbox issue, sorry 23.16.57 # hmm, also can't help but wonder if -Os would be faster than -O3 given the tiny caches (if any) on these things. 23.20.09 *** Saving seen data "./dancer.seen" 23.21.20 # <__builtin> heh, -Os causes a crash on startup 23.21.38 # <__builtin> thankfully it has a sensible PC 23.23.49 # it sounds like the SDL port is on the hairy edge of stability in the best of circumstances 23.26.38 # <__builtin> That one was a fluke, actually. Didn't sync before ejecting. 23.26.54 Join ac_laptop [0] (~ac_laptop@186.2.247.129) 23.27.34 # <__builtin> -Os averages 12.4 FPS (down from 12.8 with -O3 and 4.9.4) 23.29.47 # * speachy nods. 23.30.16 # it's hard to point the finger any anything else though until we can weed out the superfluous warnings. 23.31.27 # <__builtin> the crash on exit is also gone with -Os 23.31.47 # <__builtin> and -O2 23.32.00 # that does point the finger at unsafe code getting incorrectly optimized 23.32.09 # <__builtin> yeah, for sure 23.32.51 # * __builtin is trying to figure out what's being allocated near the address of the pointer in question 23.33.13 # <__builtin> are there any better ways of doing that than picking through the asm listing? 23.33.44 # objdump -t 23.34.43 # <__builtin> exactly what I needed 23.35.01 # I'm going to see if ipod6g compiles with the GCC 9 arm toolchain I have lying around 23.35.08 # jsut for giggles 23.37.09 # ...kaboom 23.37.23 # <__builtin> caused by? 23.38.13 # C headers being included when assembling crt0.S 23.40.17 # <__builtin> there's only preprocessor stuff in those headers, no? 23.40.40 Quit lebellium (Quit: Leaving) 23.40.44 # yeah. something's pulling in _default_types.h in the toolchain 23.42.43 # ...we're building the ASM with $CC... 23.44.36 # <__builtin> yeah? 23.44.43 # <__builtin> or is that an abuse? 23.44.53 # should be okay but something wonky is happening 23.55.46 Join ry755 [0] (~ry755@47.149.70.12) 23.57.29 # found it. we were including which isn't ASM-safe.