<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	>
<channel>
	<title>Comments on: A new lecture: Crash N&#8217; Burn</title>
	<atom:link href="http://tuxology.net/2008/06/30/a-new-lecture-crash-n-burn/feed/" rel="self" type="application/rss+xml" />
	<link>http://tuxology.net/2008/06/30/a-new-lecture-crash-n-burn/</link>
	<description>A Linux embedded, kernel and training blog</description>
	<pubDate>Tue,  6 Jan 2009 04:39:18 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.7</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Gilad Ben-Yossef</title>
		<link>http://tuxology.net/2008/06/30/a-new-lecture-crash-n-burn/comment-page-1/#comment-10</link>
		<dc:creator>Gilad Ben-Yossef</dc:creator>
		<pubDate>Wed, 20 Aug 2008 07:58:45 +0000</pubDate>
		<guid isPermaLink="false">http://tuxology.net/?p=50#comment-10</guid>
		<description>Hi Edwin,

Thanks for the feedback!

About using an alternate signal stack, - you are of course right and I in fact considered doing this, unfortunately it makes the job of printing the back trace a lot more difficult. Specifically, we can no longer simply call backtrace().

I have in my todo list to replace backtrace() with my code, both for platforms that don't have frame pointer , such as the mips and for uCLibc based platforms that don't have backtrace(). When/If I do that using an alternate sig stack certainly becomes  an option.

Regarding using pthread_atfork(), that's a really nifty and simple idea which i haven't thought about. Thanks :-)

As for the the extra "return" at the end of the function, it's a simple typo - I massaged the code to make it more simple and readable before publishing the lecture and this was simply left there by mistake.

Many thanks for the valuable feedback,
Gilad</description>
		<content:encoded><![CDATA[<p>Hi Edwin,</p>
<p>Thanks for the feedback!</p>
<p>About using an alternate signal stack, - you are of course right and I in fact considered doing this, unfortunately it makes the job of printing the back trace a lot more difficult. Specifically, we can no longer simply call backtrace().</p>
<p>I have in my todo list to replace backtrace() with my code, both for platforms that don&#8217;t have frame pointer , such as the mips and for uCLibc based platforms that don&#8217;t have backtrace(). When/If I do that using an alternate sig stack certainly becomes  an option.</p>
<p>Regarding using pthread_atfork(), that&#8217;s a really nifty and simple idea which i haven&#8217;t thought about. Thanks <img src='http://tuxology.net/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /> </p>
<p>As for the the extra &#8220;return&#8221; at the end of the function, it&#8217;s a simple typo - I massaged the code to make it more simple and readable before publishing the lecture and this was simply left there by mistake.</p>
<p>Many thanks for the valuable feedback,<br />
Gilad</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: edwin</title>
		<link>http://tuxology.net/2008/06/30/a-new-lecture-crash-n-burn/comment-page-1/#comment-9</link>
		<dc:creator>edwin</dc:creator>
		<pubDate>Tue, 19 Aug 2008 12:57:18 +0000</pubDate>
		<guid isPermaLink="false">http://tuxology.net/?p=50#comment-9</guid>
		<description>Interesting lecture. 
There are some tiny additions I would make to libcrash:
- use sigaltstack: if we get a fault because the stack was overrun, the fault handler can't run w/o sigaltstack
- use pthread_atfork() in libauto_crash and register a handler for those too, for example daemons usually do a fork() right on startup, currently LD_PRELOAD wouldn't register a handler for the forked daemon
- it would be nice if the fault handler could spawn a gdb and attach it to the (still running) faulting app. Perhaps print the PID and tell the user to attach gdb, and then go to sleep (using pselect or something) as an option
- the signal_backtrace code for i386 and ppc looks dead,  shouldn't the first return be part of an #ifndef?
	return ret;
#ifdef __i386__
	  array[distance] = (void *)(context-&#62;uc_mcontext.gregs[REG_EIP]);
#endif /* __i386__ */

#ifdef __PPC__ 
	  array[distance] = (void *)(context-&#62;uc_mcontext.regs-&#62;nip);
#endif /* __PPC__ */
	  
	return ret;</description>
		<content:encoded><![CDATA[<p>Interesting lecture.<br />
There are some tiny additions I would make to libcrash:<br />
- use sigaltstack: if we get a fault because the stack was overrun, the fault handler can&#8217;t run w/o sigaltstack<br />
- use pthread_atfork() in libauto_crash and register a handler for those too, for example daemons usually do a fork() right on startup, currently LD_PRELOAD wouldn&#8217;t register a handler for the forked daemon<br />
- it would be nice if the fault handler could spawn a gdb and attach it to the (still running) faulting app. Perhaps print the PID and tell the user to attach gdb, and then go to sleep (using pselect or something) as an option<br />
- the signal_backtrace code for i386 and ppc looks dead,  shouldn&#8217;t the first return be part of an #ifndef?<br />
	return ret;<br />
#ifdef __i386__<br />
	  array[distance] = (void *)(context-&gt;uc_mcontext.gregs[REG_EIP]);<br />
#endif /* __i386__ */</p>
<p>#ifdef __PPC__<br />
	  array[distance] = (void *)(context-&gt;uc_mcontext.regs-&gt;nip);<br />
#endif /* __PPC__ */</p>
<p>	return ret;</p>
]]></content:encoded>
	</item>
</channel>
</rss>
