Comments on: Fixing an Adium bug: A timeline http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline The personal weblog of Peter Hosey. Sun, 14 Mar 2010 12:45:37 +0000 http://wordpress.org/?v=2.9 hourly 1 By: Peter Hosey http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-119431 Peter Hosey Wed, 05 Sep 2007 05:57:27 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-119431 Already commented on it with my thanks. ☺ Already commented on it with my thanks. ☺

]]> By: Blake C. http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-119414 Blake C. Wed, 05 Sep 2007 04:15:04 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-119414 Just posted it: http://yamacdev.blogspot.com/2007/09/case-of-missing-stack-frames.html Just posted it:

http://yamacdev.blogspot.com/2007/09/case-of-missing-stack-frames.html

]]> By: Blake C. http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-117631 Blake C. Thu, 30 Aug 2007 05:42:44 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-117631 Well, I was wrong again. -fomit-frame-pointer does not result in a missing stack frame in a backtrace, at least on Intel. I'm looking into it further, blog post coming soon. Well, I was wrong again. -fomit-frame-pointer does not result in a missing stack frame in a backtrace, at least on Intel. I'm looking into it further, blog post coming soon.

]]> By: Blake C. http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-114219 Blake C. Fri, 17 Aug 2007 20:59:24 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-114219 After some more homework, it appears I didn't have all the facts exactly correct- while the tail call optimization does result in a frame being omitted from a backtrace, it's not because the frame was not established. It's just that the frame is not visible because of the nature of what seems to be referred to as a 'sibling' call. Regarding -fno-omit-frame-pointer: A stack frame can be omitted from a backtrace for 2 reasons that I know of- a tail call can render the frame invisible, or the frame can actually be omitted from the object code as a different optimization. -fno-omit-frame-pointer will prevent the latter case from happening, but will have no effect on the former. Regarding -fno-optimize-sibling-calls: I've not come across this one before, and 'man gcc' is no help. It looks like this is an area I should research more and maybe blog about... After some more homework, it appears I didn't have all the facts exactly correct- while the tail call optimization does result in a frame being omitted from a backtrace, it's not because the frame was not established. It's just that the frame is not visible because of the nature of what seems to be referred to as a 'sibling' call.

Regarding -fno-omit-frame-pointer: A stack frame can be omitted from a backtrace for 2 reasons that I know of- a tail call can render the frame invisible, or the frame can actually be omitted from the object code as a different optimization. -fno-omit-frame-pointer will prevent the latter case from happening, but will have no effect on the former.

Regarding -fno-optimize-sibling-calls: I've not come across this one before, and 'man gcc' is no help. It looks like this is an area I should research more and maybe blog about...

]]> By: Peter Hosey http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-114119 Peter Hosey Fri, 17 Aug 2007 04:13:29 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-114119 Blake C.: Aha. Interesting. Would -fno-optimize-sibling-calls or perhaps -fno-omit-frame-pointer (added to the Deployment-Debug build config) end that problem? If so, I'll add it to my list of bugs to file that that option/those options should be included in the Debug config in the project template. Blake C.: Aha. Interesting.

Would -fno-optimize-sibling-calls or perhaps -fno-omit-frame-pointer (added to the Deployment-Debug build config) end that problem?

If so, I'll add it to my list of bugs to file that that option/those options should be included in the Debug config in the project template.

]]> By: Blake C. http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-114084 Blake C. Thu, 16 Aug 2007 22:22:51 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-114084 Oops, I should clarify- not pushing %eip/%rip is a side effect of using some variant of 'jmp' rather than 'call'. This is very easy to spot in otool or otx output. Oops, I should clarify- not pushing %eip/%rip is a side effect of using some variant of 'jmp' rather than 'call'. This is very easy to spot in otool or otx output.

]]> By: Blake C. http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-114083 Blake C. Thu, 16 Aug 2007 22:16:01 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-114083 Excellent post! "This also means that zac's backtrace in #7543 is the same bug; the one in #7542 is missing a frame (for some reason)." This is most likely caused by a tail call optimization, wherein a function A can call another function B without updating the return address, for example 'b' instead of 'blr' on ppc and simply not pushing %eip/%rip in i386/x86_64. While the performance win is nice, it does have the side effect of not establishing a new stack frame for function B. If you find that this is indeed the cause of the missing stack frame, there's a handy way to force gcc to not generate the tail call- just add the following line as the last line in function A: __asm__ volatile(""); Sprinkle that where needed and stack frames will abound :) Excellent post!

"This also means that zac's backtrace in #7543 is the same bug; the one in #7542 is missing a frame (for some reason)."

This is most likely caused by a tail call optimization, wherein a function A can call another function B without updating the return address, for example 'b' instead of 'blr' on ppc and simply not pushing %eip/%rip in i386/x86_64. While the performance win is nice, it does have the side effect of not establishing a new stack frame for function B. If you find that this is indeed the cause of the missing stack frame, there's a handy way to force gcc to not generate the tail call- just add the following line as the last line in function A:

__asm__ volatile("");

Sprinkle that where needed and stack frames will abound :)

]]> By: Michael Davies http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-113850 Michael Davies Wed, 15 Aug 2007 12:50:00 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-113850 This is a great post, and should be required reading for all budding application developers! Thanks for taking the time to record it all. It's also really good to see the amount of support you could call on from the user community. Cheers, Michael This is a great post, and should be required reading for all budding application developers! Thanks for taking the time to record it all.

It's also really good to see the amount of support you could call on from the user community.

Cheers, Michael

]]> By: Adam Dempsey http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline/comment-page-1#comment-113794 Adam Dempsey Wed, 15 Aug 2007 10:29:01 +0000 http://boredzo.org/blog/archives/2007-08-14/fixing-an-adium-bug-a-timeline#comment-113794 very interesting read :) Thanks for sharing the story and thanks to all involved for the quick fix :) very interesting read :) Thanks for sharing the story and thanks to all involved for the quick fix :)

]]>