[TriLUG] Apache: Segmentation fault errors

Paul G. Szabady Paul at ThyService.com
Wed Mar 7 19:52:57 EST 2007


James,

OK, I give up.  How can I make apache dump core?  I'm not finding anything
valuable through google.  :(

-- 
Paul
@ Thy Service

> On 3/4/07, Paul G. Szabady <Paul at thyservice.com> wrote:
>> Greetings,
>>
>> I was wondering if anyone had any good pointers for trouble-shooting
>> Apache Segmentation fault errors on linux.
> It doesn't matter the application if you are getting a seg fault, look
> at the core file with gdb.  If you are not dropping cores configure
> your box to do so (actually with the 2.6 kernel you can configure
> where cores drop, a really nice feature [solaris had something
> similar]).  Anyway once you have a readable core file type something
> like:
>
>    gcb -c $path_to_core $path_to_executable
>
> Then type:
>
>    bt
>
> This will print a back trace, and that will tell you which subroutine
> the the program was in when it died.   Even if you don't know enough
> to do something with this information, its a great thing to paste into
> a bug report or email to the maintainer (I always start with the
> distro I'm using and start going upstream from there).
> If you do know what to make of a back trace, you can usually (though
> not always) figure out exactly what the problem is, and fix it.
>
> That said not all core dumps are actually bugs in the program.  Many
> times programs will core dump, like the kernel panics when certain
> things are expected to be a certain way and they are not (this is
> called an assert).   The thinking is that to do anything else except
> drop core could cause serious problems.  Some of these asserts catch
> bugs, but others catch problems in the OS, libraries, your sysem setup
> or your hardware (in some cases it could be your just out of memory,
> and it happened that that last malloc was real critical).
>
> All that said most core dumps are due to lazy or tired programmers not
> validating their data properly (well, and no matter how rigorous you
> are in you approach to coding sometimes the neorons simply misfire).
>
> Chers...james
> --
> TriLUG mailing list        : http://www.trilug.org/mailman/listinfo/trilug
> TriLUG Organizational FAQ  : http://trilug.org/faq/
> TriLUG Member Services FAQ : http://members.trilug.org/services_faq/
>




More information about the TriLUG mailing list