[ python-Bugs-1000555 ] BE crashes server process on CREATE FUNCTION.
noreply at pgfoundry.org
noreply at pgfoundry.org
Wed Mar 15 17:26:34 GMT 2006
Bugs item #1000555, was opened at 2006-02-16 01:03
You can respond by visiting:
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000555&group_id=1000094
Category: BE/TEOP
Group: None
Status: Open
Resolution: Accepted
Priority: 3
Submitted By: Nobody (None)
Assigned to: James Pye (jwp)
Summary: BE crashes server process on CREATE FUNCTION.
Initial Comment:
When using psql to load a CREATE OR REPLACE FUNCTION script the Postgres server will sometimes crash. See attached file for server log. The problem seems to arise when making a change to the script file. The function I was working with is as follows.
create or replace function py_test(varchar) returns varchar
language python as
$Body$
return str(args[0]+'no')
$Body$
If I change the line
return str(args[0]+'no') to
return args[0]+'no' or vica versa
I can generally cause the server to crash.
When I am doing this I have one psql session open to run the function and am loading the function by invoking psql -d test -f fnc_py_test.sql in another session.
Postgres 8.1.3,Python 2.4.2, BE 0.3 checked out from CVS about an hour ago.
----------------------------------------------------------------------
Comment By: Adrian Klaver (aklaver)
Date: 2006-03-15 17:26
Message:
Downloaded new be from CVS and built it. I was able to modify the function without crashing the server. Seems this bug is gone.
----------------------------------------------------------------------
Comment By: James Pye (jwp)
Date: 2006-03-15 02:30
Message:
Please try this again with the latest head. I have fixed an off by one error that I believe fixes this issue.
----------------------------------------------------------------------
Comment By: James Pye (jwp)
Date: 2006-02-19 06:00
Message:
Okay, I think I have reproduced it on my linux(redhat) work box. It appears to be a strange problem, and, honestly, I'm not sure yet that it's my fault. While I would expect it to be a plpy issue, the crash is occuring in some Python tokenization function after glibc complains of memory corruption. I tried to turn down the optimization level to see if that would help, but none could be found. If it is my fault, I can only imagine it being a resource cleanup issue that sets it up for the actual failure as gdb shows no fault of mine(no null pointer of any sort, and the string I'm passing into the Python APIs seem clean; additionally, this issue simply does not exist on FreeBSD and Darwin).
If this issue exists on a given platform, one can likely reproduce the issue by continually creating functions in the same session.
Can you, submitter, or anyone else test this on other platforms?
----------------------------------------------------------------------
Comment By: James Pye (jwp)
Date: 2006-02-16 04:55
Message:
Okay, I have failed to reproduce it on a FreeBSD box. However, I'm thinking it's portability issue as I know my tests fail miserably on redhat. I'm anticipating that your recurring replacement of the function is drawing it out somehow. Hopefully it will be the only one. :(
----------------------------------------------------------------------
Comment By: James Pye (jwp)
Date: 2006-02-16 01:44
Message:
I'll try to reproduce this when I get home.
----------------------------------------------------------------------
You can respond by visiting:
http://pgfoundry.org/tracker/?func=detail&atid=442&aid=1000555&group_id=1000094
More information about the Python-general
mailing list