| 00:04.31 | *** join/#edev dalias (dalias@216-12-86-13.cv.mvl.ntelos.net) |
| 00:05.14 | *** join/#edev file (~file@asterisk/developer-and-muffin-lover/file) |
| 00:05.37 | *** join/#edev armin76 (~armin@gentoo/developer/armin76) |
| 00:36.58 | *** join/#edev djerome (~djerome@ip68-98-228-41.ph.ph.cox.net) |
| 01:46.50 | *** join/#edev jann (~jann@2a00:1a28:1101:63f:1337::948) |
| 02:00.51 | *** join/#edev Belliash (~belliash@asiotec/constitutive/belliash) |
| 02:47.43 | *** join/#edev flo_lap (~fuchs@sign-4d094a49.pool.mediaWays.net) |
| 02:47.45 | *** join/#edev flo_lap (~fuchs@Maemo/community/contributor/florian) |
| 04:44.59 | *** join/#edev TheSeven (~quassel@rockbox/developer/TheSeven) |
| 06:30.22 | *** join/#edev clio (~andrej@85.159.109.222) |
| 09:40.47 | *** join/#edev Anaphaxeton (~george@unaffiliated/anaphaxeton) |
| 10:38.00 | *** join/#edev damkerngt (~user@171.6.227.240) |
| 11:26.22 | *** join/#edev damkerngt (~user@14.207.233.153) |
| 11:47.02 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 11:57.19 | *** join/#edev rened (~rened@2a02:8100:c001:12::242) |
| 12:12.49 | *** join/#edev damkerngt (~user@27.130.6.75) |
| 13:41.47 | *** join/#edev Crofton (~balister@12.199.200.124) |
| 14:07.29 | *** join/#edev gustavoz (~gustavoz@host98.190-227-168.telecom.net.ar) |
| 14:25.16 | *** part/#edev mozmck (~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com) |
| 14:29.20 | *** join/#edev _av500_ (~av500@lgf.archos.com) |
| 15:15.53 | *** join/#edev mozmck (~moses@client-67.210.159.209.dfwtx.partnershipbroadband.com) |
| 15:29.12 | *** join/#edev _av500_ (~av500@lgf.archos.com) |
| 15:53.33 | *** join/#edev das_plague (~danders@rrcs-97-77-26-26.sw.biz.rr.com) |
| 15:55.04 | *** join/#edev prp^2 (~prpplague@107-206-64-184.lightspeed.rcsntx.sbcglobal.net) |
| 16:10.44 | *** join/#edev Crofton (~balister@32.159.230.110) |
| 16:18.32 | *** join/#edev MonMotha (~monmotha@2001:470:c5f2:1:224:7eff:fedc:893e) |
| 17:12.32 | *** join/#edev prpplague (~danders@rrcs-97-77-26-26.sw.biz.rr.com) |
| 17:19.21 | *** join/#edev Crofton (~balister@sccc-66-78-236-243.smartcity.com) |
| 17:46.41 | *** join/#edev sndcrb (~sndcrb@dsl-hkibrasgw2-50de26-12.dhcp.inet.fi) |
| 17:52.16 | *** join/#edev sjhill (~sjhill@173-25-243-3.client.mchsi.com) |
| 17:52.17 | *** mode/#edev [+o sjhill] by ChanServ |
| 17:54.27 | *** join/#edev sjhill (~sjhill@173-25-243-3.client.mchsi.com) |
| 17:54.29 | *** mode/#edev [+o sjhill] by ChanServ |
| 18:03.05 | *** join/#edev landley (~landley@70.114.134.56) |
| 18:03.30 | landley | MonMotha: I need to mail that box back. |
| 18:03.41 | landley | (I started new day job at Pace last week.) |
| 18:03.49 | MonMotha | landley: yeah, any time. I sent you my address |
| 18:04.03 | landley | Ah, still about 9 days behind on email. I'll catch up. :) |
| 18:21.10 | *** join/#edev Crofton (~balister@sccc-66-78-236-243.smartcity.com) |
| 19:05.27 | *** join/#edev Crofton (~balister@sccc-66-78-236-243.smartcity.com) |
| 19:27.59 | *** join/#edev landley (~landley@70.114.134.56) |
| 20:24.18 | wmat | landley: the Canadian Pace? |
| 20:25.05 | landley | pace.com |
| 20:25.08 | landley | Is there more than one? |
| 20:25.24 | wmat | http://pacetechnologies.com/ |
| 20:26.54 | landley | wmat: well the one I'm working for is pace.com's austin branch. |
| 20:35.15 | wmat | ah, not the same |
| 21:56.13 | *** join/#edev darknighte_znc (~darknight@nat-lmt.mentorg.com) |
| 21:56.33 | *** join/#edev darknighte (~darknight@pdpc/supporter/professional/darknighte) |
| 22:01.29 | *** join/#edev g1powermac (~g1powerma@unaffiliated/g1powermac) |
| 22:18.16 | *** join/#edev orbarron (~orbarron@nat/ti/x-mbgyjymjlnmzfvpm) |
| 23:00.01 | MonMotha | landley: if they need hardware design, let me know :) |
| 23:00.44 | landley | http://ellcc.org/blog/?p=251 |
| 23:00.55 | landley | LLVM native toolchains. |
| 23:00.57 | landley | Huzzah. |
| 23:14.29 | *** join/#edev gkwhc (~gkwhc@unaffiliated/gkwhc) |
| 23:17.58 | gkwhc | Hi everyone! I am trying to debug a code (that runs on RTOS) that executes in a while loop, but randomly falls out of it less than 1sec of execution. It does this consistently..what are some debug strategies for this strange phenomenon? |
| 23:18.47 | landley | gkwhc: step 1: get more info than that. |
| 23:19.00 | landley | falls out to where? |
| 23:19.34 | landley | does the loop have a test, or break statements? |
| 23:19.40 | *** join/#edev groglogic (~groglogic@24.54.165.149) |
| 23:20.17 | landley | Is a signal/interrupt handler triggering and doing a longjmp variant somewhere? |
| 23:20.24 | landley | (watchdog?) |
| 23:20.28 | landley | what rtos? |
| 23:20.35 | landley | Do you have a jtag? |
| 23:20.43 | landley | Can you stick in print statements to a serial port? |
| 23:20.47 | landley | As I said: need more info. |
| 23:20.48 | gkwhc | landley: falls out of the while loop. the while loop basically takes audio in and outputs it in audio out. I'd also like to add that when I put breakpoints or printf statements in the loop, the bug does not appear |
| 23:21.28 | landley | gkwhc: create a global variable and write your current position to the global variable. |
| 23:21.29 | gkwhc | i am using DSP/BIOS for TI's line of DSPs |
| 23:21.43 | landley | Then check the global after it falls out of the loop and it'll tell you the last statement that set it, as long as each set is unique. |
| 23:21.57 | landley | Shouldn't affect timing or stack usage or similar enough to perturb the heisenbug. |
| 23:22.34 | landley | You can even make it a char * and instead of printing the string, set the char * and print the char * after the loop. |
| 23:23.23 | landley | When you say it "falls out",does it execute the statement after the while loop, or reset to the entry point of the program? |
| 23:24.44 | gkwhc | landley: it does not execute the statement after the loop, but is observed to jump to an "idle task" by blinking LEDs. the loop is contained in a "task" that has higher priority than the "idle task" |
| 23:27.04 | gkwhc | i just tried setting a breakpoint to the statement after the while loop, but breakpoint cannot be activated (because theres no associated code) even with optimization turned off |
| 23:27.12 | roxfan | it's probably just waiting for i/o then |
| 23:27.32 | roxfan | so idle task get a chance to run for a bit |
| 23:28.19 | MonMotha | how is LLVM's ARM output, these days? |
| 23:28.25 | gkwhc | hmm could be, since when i inserted printfs or breakpoints, everything runs fine |
| 23:28.34 | MonMotha | last I heard it was darn good on x86 but still noticeably lacking compared to GCC on ARM |
| 23:29.18 | roxfan | MonMotha: apple seems to be happy since iOS is clang-only for a couple years now |
| 23:29.30 | MonMotha | hum, that says something I guess |
| 23:30.14 | landley | gkwhc: that's why the "set a global variable to see if execution got to this point" trick is helpful. |
| 23:30.23 | landley | MonMotha: building ellcc to find out. |
| 23:32.12 | landley | I'm telling the ellcc guy about the aboriginal package cache, and offering to port it to his project so the svn checkout doesn't have to take 20 minutes... |
| 23:32.56 | *** join/#edev Crofton (~balister@64-186-172-226.static-ip.telepacific.net) |
| 23:35.24 | gkwhc | landley: ok i'll try that. this means i'll need to put the statement at multiple locations right? |
| 23:43.30 | landley | The assignment, yeah. |
| 23:43.45 | landley | Make one global, assign a unique cookie into it at every place you want to know "did the code get here". |
| 23:43.52 | landley | When you read it out, you see the last place the code got before you read it. |
| 23:44.13 | landley | And it's narrow enough not to perturb most heisenbugs. |
| 23:49.31 | MonMotha | it may save you some hair pulling to declare it volatile |
| 23:49.41 | MonMotha | it'll tell the optimizer to not re-order things too badly |
| 23:50.38 | gkwhc | landley: except theres one problem-if i put it in an IO routine, then I wouldnt know if the variable is set when the code is working or when execution falls out of place |
| 23:51.12 | landley | gkwhc: you know the last place it was set. |
| 23:51.16 | landley | That would be the last place the code got to. |
| 23:51.38 | landley | so set it to one thing in the I/O routine, and another in the main loop on return from the I/O routine. |
| 23:51.53 | landley | Narrow it down to the last line that gets executed before it goes elsewhere, just like you would with printfs. |
| 23:52.19 | landley | (or breakpoints) |
| 23:53.12 | gkwhc | i see |
| 23:53.15 | landley | You can even set up tests where if we got here but the value is this, printf(stuff) because that shouldn't have happened so the variable state is now interesting. |
| 23:53.34 | landley | so the printf screwing up the heisenbug no longer matters: dump and hang, then reset the box for the next test. |
| 23:54.24 | landley | This is "the debugging trick". |
| 23:54.43 | landley | I've done this trick by beeping the speaker, flashing an LED, whatever output mechanism I had. |
| 23:54.47 | MonMotha | does the hardware support memory watchpoints? |
| 23:54.55 | landley | "Did the code get here, Y/N". |
| 23:55.12 | landley | "When it got here, was this variable equal to this Y/N". |
| 23:55.20 | landley | You can get surprisingly far with that... |
| 23:56.44 | MonMotha | yep |
| 23:56.59 | MonMotha | bonus points for putting the little "status variable" on some spare GPIOs and watching it on a scope |
| 23:57.16 | MonMotha | (or logic analyzer) |
| 23:59.12 | gkwhc | good strategy. im getting closer and closer :) |