10:13 < stuarta> where is the thread ID of the crashing thread in the Ubuntu backtraces? 10:14 < stuarta> dammit, they've cut off the most important 3 lines in the gdb backtrace... 10:15 < gardengnome> stuarta: have you read yesterday's discussion? 10:15 < stuarta> yeah, i saw much of it while lurking 10:15 < gardengnome> it seems the backtraces are useless anyways. :( 10:16 < stuarta> i'm currently digging around the aport stuff on the website. 10:16 < gardengnome> we'll be working on creating usable backtraces. 10:17 < stuarta> do you know the bit i mean in the gdb backtrace? 10:18 < gardengnome> no, i actually didn't look at the backtraces themselves 10:18 < gardengnome> to me, it's just gibberish. :) 10:19 < stuarta> http://pastebin.ca/539602 10:19 < stuarta> that's the 3 missing lines off the top of the backtrace. 10:19 < gardengnome> stuarta: which ticket number is that? 10:20 < stuarta> tells me 1. why it died 2. where it died (threadid & file, linenum) 10:20 < stuarta> gardengnome: that's just a random ffmpeg backtrace i had lying around 10:20 < gardengnome> ah 10:20 < stuarta> but it illustrates the stuff i'd like in backtraces (as well as useful line numbers from the dbg build) 10:20 < gardengnome> stuarta: i suppose we don't get those because we --enable-proc-opt. :) 10:20 < gardengnome> sure. 10:21 < stuarta> not true. i enable proc opt and still get them 10:21 < gardengnome> interesting. 10:21 < stuarta> i do however always build the debug release 10:21 < gardengnome> is apport broken then? 10:21 < gardengnome> stuarta: we're also doing --compile-type=debug 10:23 < stuarta> imagine for a moment you had a multithreaded program with several threads doing similar things 10:23 * gardengnome does so 10:23 < stuarta> you'd have trouble working out which thread was at fault if they are all working in the same area of code 10:24 < stuarta> mythbackend often does this, if say you are recording 2 different things at once 10:24 < gardengnome> true 10:25 < Anduin> we should add 'info program' to the debug howto 10:27 < gardengnome> stuarta: that's an interesting finding. i'll forward it to someone more knowledgeable. 10:28 < stuarta> thanks 10:33 < gbee> the extra debugging symbols would enable use to find the exact line at which the crashing occurs e.g. #3536 just says that it occured in GuideGrid::fillProgramRowInfos 10:34 < gbee> that function is nearly 240 lines long - so figuring out precisely where or why it crashes is that much harder 10:35 < gardengnome> like the proverbial needle in a haystack :( 10:35 < stuarta> i've a good mind to close 3565 as fixed in head 10:36 < gbee> gardengnome: it's doable, but it's nowhere near as quick and easy as it would be if we knew the precise line 10:36 < gbee> I actually really like the idea of automated backtraces and reporting tools, if you can get apport providing the right information then it would be very valuable 10:37 < gbee> I can't think how many people claim that mythfrontend/mythbackend has segfaulted on them at some time, but most of those people cannot produce a backtrace or can't even reproduce the crash 10:38 < gardengnome> i bet that "most people" are too lazy. that's why i like the idea of having apport generate backtraces automatically 10:39 < stuarta> i'll agree, it's a lot better than some of the other automated backtrace generators. 10:39 < gbee> It could improve the stability of myth for most people a lot if these edge and corner case segfaults were addressed 10:40 < gardengnome> we just need to get good backtraces :) 10:42 < gardengnome> launchpad makes me want to bang my head against a wall, though 10:44 < gardengnome> i created a "blueprint" last night: https://blueprints.launchpad.net/mythtv/+spec/mythtv-sane-dbg-symbols 10:44 < gardengnome> i'll update it with today's results. thanks for the input :) 10:44 < gardengnome> i created a "blueprint" last night: https://blueprints.launchpad.net/mythtv/+spec/mythtv-sane-dbg-symbols 10:44 < gardengnome> i'll update it with today's results. thanks for the input :)