Menu
▾
▴
pypgsql-users
|
From: Craig M. <cr...@th...> - 2003-04-19 08:38:43
|
Hi all, Can anyone point me in the right direction for solving this? I am running Gentoo. Running python test/PgSQLTestCases.py gives a segfault. I have narrowed it down to the "from pyPgSQL import PgSQL" line. Any ideas? TIA Craig -- Craig Main RHCE ST Solutions Cell: 082-323-4670 Home Tel: 011-760-1900 AIM: SATuxman; ICQ: 75815570 |
|
From: <gh...@gh...> - 2003-04-19 09:36:39
|
Craig Main wrote: > Hi all, > > Can anyone point me in the right direction for solving this? I am > running Gentoo. Running python test/PgSQLTestCases.py gives a segfault. > I have narrowed it down to the "from pyPgSQL import PgSQL" line. > > Any ideas? Does "from pyPgSQL import libpq" segfault already, too? Can you try the following: 1) Build pyPgSQL with debugging info: $ python setup.py build --debug 2) Under bash, enter: "ulimit -c unlimited" 3) Run the test suite. You'll get a core file (let's suppose it's called python.core). 4) Fire up gdb and load the core file, then show the backtrace: gdb> core python.core gdb> backtrace Do you see anything that makes sense there? Could you post the traceback? -- Gerhard |
|
From: Craig M. <cr...@th...> - 2003-04-22 06:01:49
|
On Sat, 2003-04-19 at 11:37, Gerhard H=E4ring wrote: > Craig Main wrote: > > Hi all, > >=20 > > Can anyone point me in the right direction for solving this? I am > > running Gentoo. Running python test/PgSQLTestCases.py gives a segfault. > > I have narrowed it down to the "from pyPgSQL import PgSQL" line. > >=20 > > Any ideas? >=20 > Does "from pyPgSQL import libpq" segfault already, too? >=20 yes > Can you try the following: >=20 > 1) Build pyPgSQL with debugging info: >=20 > $ python setup.py build --debug >=20 > 2) Under bash, enter: "ulimit -c unlimited" >=20 > 3) Run the test suite. You'll get a core file (let's suppose it's called=20 > python.core). >=20 > 4) Fire up gdb and load the core file, then show the backtrace: > gdb> core python.core > gdb> backtrace >=20 > Do you see anything that makes sense there? Could you post the traceback? >=20 This is what I get in the backtrace: (gdb) core core Core was generated by `python PgSQLTestCases.py'. Program terminated with signal 11, Segmentation fault. #0 0x402a6637 in ?? () #0 0x402a6637 in ?? () #1 0x402aa7dc in ?? () #2 0x080dd21d in ?? () #3 0x08078bb2 in ?? () #4 0x08079569 in ?? () #5 0x0807baa7 in ?? () #6 0x08095896 in ?? () #7 0x08097ff0 in ?? () #8 0x0809604b in ?? () #9 0x08096e73 in ?? () #10 0x08096a09 in ?? () #11 0x08098518 in ?? () #12 0x080979ec in ?? () #13 0x080df356 in ?? () #14 0x080dd21d in ?? () #15 0x080bca99 in ?? () #16 0x0807a2e5 in ?? () #17 0x080785f1 in ?? () #18 0x08079569 in ?? () #19 0x0807baa7 in ?? () #20 0x08095896 in ?? () #21 0x08097ff0 in ?? () #22 0x0809604b in ?? () #23 0x0809837c in ?? () #24 0x080961a2 in ?? () #25 0x08096e73 in ?? () #26 0x08096c63 in ?? () #27 0x08098598 in ?? () #28 0x080979ec in ?? () #29 0x080df356 in ?? () #30 0x080dd21d in ?? () #31 0x080bca99 in ?? () #32 0x0807a2e5 in ?? () #33 0x080785f1 in ?? () #34 0x08079569 in ?? () #35 0x0807baa7 in ?? () #36 0x08095896 in ?? () #37 0x08097ff0 in ?? () #38 0x0809604b in ?? () #39 0x08096e73 in ?? () #40 0x08096c63 in ?? () #41 0x08098598 in ?? () #42 0x080979ec in ?? () #43 0x080df356 in ?? () #44 0x080dd21d in ?? () #45 0x080bca99 in ?? () #46 0x0807a2e5 in ?? () #47 0x080785f1 in ?? () #48 0x08079569 in ?? () #49 0x0807baa7 in ?? () #50 0x080a085b in ?? () #51 0x080a006d in ?? () #52 0x08053460 in ?? () #53 0x08052fcb in ?? () #54 0x4018c7a7 in ?? () TIA Craig > -- Gerhard >=20 >=20 > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Pypgsql-users mailing list > Pyp...@li... > https://lists.sourceforge.net/lists/listinfo/pypgsql-users --=20 Craig Main RHCE ST Solutions Cell: 082-323-4670 Home Tel: 011-760-1900 AIM: SATuxman; ICQ: 75815570 |
|
From: <gh...@gh...> - 2003-04-22 14:15:06
Attachments:
debug_patch.dif
|
Craig Main wrote: > On Sat, 2003-04-19 at 11:37, Gerhard Häring wrote:> >>Craig Main wrote: >>>Hi all, >>> >>>Can anyone point me in the right direction for solving this? I am >>>running Gentoo. Running python test/PgSQLTestCases.py gives a segfault. >>>I have narrowed it down to the "from pyPgSQL import PgSQL" line. >>> >>>Any ideas? >> >>Does "from pyPgSQL import libpq" segfault already, too? > > yes > > This is what I get in the backtrace: > > (gdb) core core > Core was generated by `python PgSQLTestCases.py'. > Program terminated with signal 11, Segmentation fault. > #0 0x402a6637 in ?? () > #0 0x402a6637 in ?? () > #1 0x402aa7dc in ?? () > [...] Ouch. This isn't useful :-( To debug these kind of crashes we'll need to add diagnostic output to the C sources. Could you please apply the attached patch to libpqmodule.c (the patch is against pyPgSQL 2.3) and post the output of a "from pyPgSQL import libpq" ? Thanks, -- Gerhard |
|
From: Craig M. <cr...@th...> - 2003-04-23 06:01:24
|
On Tue, 2003-04-22 at 16:16, Gerhard H=E4ring wrote: > Ouch. This isn't useful :-( >=20 > To debug these kind of crashes we'll need to add diagnostic output to=20 > the C sources. Could you please apply the attached patch to=20 > libpqmodule.c (the patch is against pyPgSQL 2.3) and post the output of=20 > a "from pyPgSQL import libpq" ? >=20 With the patch compiled in, and using a this file test.py containing: #!/usr/bin/python from pyPgSQL import libpq I get this output: laptop test # python test.py=20 FILE: libpqmodule.c, LINE: 950 FILE: libpqmodule.c, LINE: 952 FILE: libpqmodule.c, LINE: 954 FILE: libpqmodule.c, LINE: 956 FILE: libpqmodule.c, LINE: 963 FILE: libpqmodule.c, LINE: 965 FILE: libpqmodule.c, LINE: 967 FILE: libpqmodule.c, LINE: 969 FILE: libpqmodule.c, LINE: 971 FILE: libpqmodule.c, LINE: 973 FILE: libpqmodule.c, LINE: 975 FILE: libpqmodule.c, LINE: 980 FILE: libpqmodule.c, LINE: 982 FILE: libpqmodule.c, LINE: 1101 FILE: libpqmodule.c, LINE: 1162 Regards Craig --=20 Craig Main RHCE ST Solutions Cell: 082-323-4670 Home Tel: 011-760-1900 AIM: SATuxman; ICQ: 75815570 |
|
From: <gh...@gh...> - 2003-04-23 12:49:35
|
Craig Main wrote: > On Tue, 2003-04-22 at 16:16, Gerhard Häring wrote: > > >>Ouch. This isn't useful :-( >> >>To debug these kind of crashes we'll need to add diagnostic output to >>the C sources. Could you please apply the attached patch to >>libpqmodule.c (the patch is against pyPgSQL 2.3) and post the output of >>a "from pyPgSQL import libpq" ? >> > > With the patch compiled in, and using a this file test.py containing: > > #!/usr/bin/python > > from pyPgSQL import libpq > > I get this output: > > laptop test # python test.py > FILE: libpqmodule.c, LINE: 950 > FILE: libpqmodule.c, LINE: 952 > FILE: libpqmodule.c, LINE: 954 > FILE: libpqmodule.c, LINE: 956 > FILE: libpqmodule.c, LINE: 963 > FILE: libpqmodule.c, LINE: 965 > FILE: libpqmodule.c, LINE: 967 > FILE: libpqmodule.c, LINE: 969 > FILE: libpqmodule.c, LINE: 971 > FILE: libpqmodule.c, LINE: 973 > FILE: libpqmodule.c, LINE: 975 > FILE: libpqmodule.c, LINE: 980 > FILE: libpqmodule.c, LINE: 982 > FILE: libpqmodule.c, LINE: 1101 > FILE: libpqmodule.c, LINE: 1162 Ok, so it doesn't actually die in the module initialization phase of the C module. Could you please add print statements into pyPgSQL/libpq/__init__.py so to show where it dies there? (This sounds like an obscure bug to me, perhaps caused by too agressive compiler settings that trigger a gcc bug.) -- Gerhard |
|
From: Craig M. <cr...@th...> - 2003-04-25 13:19:41
|
On Wed, 2003-04-23 at 14:47, Gerhard H=E4ring wrote: > Ok, so it doesn't actually die in the module initialization phase of the=20 > C module. Could you please add print statements into=20 > pyPgSQL/libpq/__init__.py so to show where it dies there? >=20 > (This sounds like an obscure bug to me, perhaps caused by too agressive=20 > compiler settings that trigger a gcc bug.) >=20 Good news (maybe) for the pypgsql team, I seem to have tracked the problem down to the "from mx import DateTime" line in the PgSQL.py file. Running the that line from the python shell segfaults. So it appears that the root cause of the segfaulting is not the pypgsql code. The line "from pyPgSQL import libpq" does not crash... Any ideas? I dont seem to find a mx-dev list anywhere? TIA Craig --=20 Craig Main RHCE ST Solutions Cell: 082-323-4670 Home Tel: 011-760-1900 AIM: SATuxman; ICQ: 75815570 |
|
From: Karsten H. <Kar...@gm...> - 2003-04-25 14:20:27
|
On a perhaps related note: When I select age(dob) from identity where id='something'; (where dob is "time stamp with timezone") I am handed back a DateTimeDelta object, which however, is empty for all practical purposes. Reading the mx docs shows that they do age related calculations with RelativeDateTime. Now, I don't claim to fully comprehend the difference between DateTimeDelta and RelativeDateTime but it seems that age(dob) should return a RelativeDateTime object. Am I missing something here ? Karsten -- GPG key ID E4071346 @ wwwkeys.pgp.net E167 67FD A291 2BEA 73BD 4537 78B9 A9F9 E407 1346 |
|
From: Gerhard H. <gh...@gh...> - 2003-04-25 13:42:33
|
Craig Main wrote: > On Wed, 2003-04-23 at 14:47, Gerhard Häring wrote: > >>Ok, so it doesn't actually die in the module initialization phase of the >>C module. Could you please add print statements into >>pyPgSQL/libpq/__init__.py so to show where it dies there? >> >>(This sounds like an obscure bug to me, perhaps caused by too agressive >>compiler settings that trigger a gcc bug.) > > Good news (maybe) for the pypgsql team, I seem to have tracked the > problem down to the "from mx import DateTime" line in the PgSQL.py file. > Running the that line from the python shell segfaults. So it appears > that the root cause of the segfaulting is not the pypgsql code. The line > "from pyPgSQL import libpq" does not crash... > > Any ideas? If you've compiled your Python with --with-pymalloc, mxDateTime will crash. IIRC this has been fixed in the latest mxExtensions beta. I'd recommend that you recompile Python and mxDateTime with safe settings (no -O3, --with-pymalloc, -march=athlonxp or any such fancy things). If it's not a mxDateTime bug, it's likely that you've hit code generator or optimizer bug in your compiler. This happens more frequently than you'd probably think. >I dont seem to find a mx-dev list anywhere? http://www.egenix.com/mailman/listinfo/egenix-users -- Gerhard |
|
From: Craig M. <cr...@th...> - 2003-04-25 15:47:23
|
Thanks!! >=20 > If you've compiled your Python with --with-pymalloc, mxDateTime will=20 > crash. IIRC this has been fixed in the latest mxExtensions beta. >=20 > I'd recommend that you recompile Python and mxDateTime with safe=20 > settings (no -O3, --with-pymalloc, -march=3Dathlonxp or any such fancy=20 > things). If it's not a mxDateTime bug, it's likely that you've hit code=20 > generator or optimizer bug in your compiler. This happens more=20 > frequently than you'd probably think. >=20 Recompiled Python and mx without any optimisation flags, and now it all works. Thanks for all the help Regards Craig --=20 Craig Main RHCE ST Solutions Cell: 082-323-4670 Home Tel: 011-760-1900 AIM: SATuxman; ICQ: 75815570 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X