Skip to Content.
Sympa Menu

freetds - Re: apache php module crashing when accessing freet ds libraries

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT schemamania.org>
  • To: "TDS Development Group" <freetds AT franklin.metalab.unc.edu>
  • Subject: Re: apache php module crashing when accessing freet ds libraries
  • Date: Thu, 14 Nov 2002 23:28:00 -0500


On 14 Nov 2002 16:18:55 -0600, Chris <ccortner AT cvol.net> wrote:
> I only have a little bit of experience with gdb none with using it to
> debug libraries. If you tell me what I need to do I'll do it, if
> anything for the educational value. Otherwise I'm going home for the
> night and I'll have to send you a backtrace sometime tommorow.

Hey, tomorrow's another day, right? Didn't Scarlett say so?

I hope I don't lead you on a wild goose chase; it's just that I can't
think of a more definitive answer than a bt. I really should write this
up in the docs, because you're not the first fellow needing guidance. I
have to warn you, though, I'm not an Apache or PHP guy. I write C++ and
SQL for a living. That means I can't really give you detailed
instructions.

The good news is that if we determine it's not a FreeTDS problem (which I
fear it may be), you won't have to repeat this effort. You can send the
same bt to the PHP boys.

First I should refer you to
http://www.freetds.org/userguide/x2099.htm

which contains the earlier cautionary note that there is normally some
environmental difference. I'll remind others following along that the
assertion here is that the environments are in fact identical, but that
the script runs fine from the command line and bombs under apache.

Before starting with gdb, you should make sure the symbols haven't been
stripped (cf. strip(1)) from the executable. Otherwise, we'll be looking
at a machine eye view of the code, and, well, I won't be able to help you.
Use ldd(1) to check the executable's linkage, and file(1) to make sure it
and the relevant libraries are not stripped. For instance:

$ file *syb*so*
libsybdb.so.1.0: NetBSD/i386 demand paged shared library not stripped
libsybdb.so.2.0: NetBSD/i386 demand paged shared library not stripped

If the segfault left a .core file around and the executable isn't
stripped, it might be possible to do a bt on it (gdb --core=httpd.core).
I haven't had much luck with that; I think it's because it doesn't work
with shared libraries. Maybe a real expert could explain why.

What we want to do is start apache within gdb, and we don't want it to go
into daemon mode or spawn children. My apache docs say that's the -X
switch.

I think easiest is to make yourself a little .gdbinit file containing
macros for gdb to execute when it starts. That file would be in the
current directory (wherever you launch gdb from) and would have:

set args -X
directory /path/to/PHP/stuff
directory /path/to/FreeTDS/stuff

Then:

$ script bt
$ gdb httpd
(gdb) run
[go to your test script and execute it against this server]
segfault yada yada.....
(gdb) bt 9
[nine levels of unwraithlike call stack information]
(gdb) quit
$ ^D # closes script file "bt"

and send us the file that script(1) logged for you.

Or something along those lines.

> Thanks for all the help so far.

Surely. Thanks for your patience. One way or another, one of us will
learn something.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page