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 :)