<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 1, 2014 at 12:30 PM, bruce <span dir="ltr"><<a href="mailto:badouglas@gmail.com" target="_blank">badouglas@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi guys.<br>
<br>
running an app in both fed/centos test machines and getting a seg fault.<br>
<br>
I know this is a bit off topic, but it does related to segfault<br>
crashes, and how to get/setup the data to analyze track down the<br>
offending code!<br>
<br>
to begin,<br>
the system has /var/log/messages with<br>
Sep 30 11:40:57 dell2 kernel: courseSectionDa[3270]: segfault at 868<br>
ip 00007f80e8e1e410 sp 00007fffe404d0c8 error 4 in<br>
libgearman.so.8.0.0[7f80e8e18000+26000]<br>
<br>
isn't this saying the crash is coming from the libgearman.so.8.0.0 as<br>
opposed to the parent php app which uses the gearman lib??<br>
<br>
and assuming that this is the case, and i installed the gearman so<br>
with yum (without source) is there a way I can setup the system to<br>
capture the crash data to do an analysis of the crash??<br>
<br>
the parent app runs multiple (1000s) of times, and somewhere the crash occurs..<br>
<br>
thanks guys..<br>
<span class=""><font color="#888888">--<br>
users mailing list<br>
<a href="mailto:users@lists.fedoraproject.org">users@lists.fedoraproject.org</a><br>
To unsubscribe or change subscription options:<br>
<a href="https://admin.fedoraproject.org/mailman/listinfo/users" target="_blank">https://admin.fedoraproject.org/mailman/listinfo/users</a><br>
Fedora Code of Conduct: <a href="http://fedoraproject.org/code-of-conduct" target="_blank">http://fedoraproject.org/code-of-conduct</a><br>
Guidelines: <a href="http://fedoraproject.org/wiki/Mailing_list_guidelines" target="_blank">http://fedoraproject.org/wiki/Mailing_list_guidelines</a><br>
Have a question? Ask away: <a href="http://ask.fedoraproject.org" target="_blank">http://ask.fedoraproject.org</a><br></font></span></blockquote><div><br></div><div>you may find tools like strace to see what, in terms of system calls, preceded the crash.<br><br></div><div>note the -f option to follow new sub processes.<br><br></div><div>pstree can be fun, ...<br><br></div><div>try, ...<br><br>watch "pstree -p 1638"<br><br><br></div><div>where '1638' is a processes spewing subprocesses of interest.<br><br></div><div>hth, ... <br><br></div><div>sudo yum install strace watch pstree<br><br><br></div></div><br></div></div>