"Marko Kreen" <markokr@gmail.com> writes: > Following function crashes plpython on x86-64 / gcc 4.1.2 / debian 4.0: > CREATE FUNCTION crashme(str_len integer) > RETURNS text AS $$ > raise Exception("X" * str_len) > $$ LANGUAGE plpythonu; > SELECT crashme(1000); > Problem turns out to be va_list handling in PLy_vprintf() which > uses same va_list repeatedly. Fix is to va_copy to temp variable. This patch isn't acceptable because va_copy() isn't portable. I'm kinda wondering why PLy_printf and the functions after it even exist. They look like rather poorly done reimplementations of functionality that exists elsewhere in the backend (eg, stringinfo.c). In particular, why malloc and not palloc? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > Tom Lane escribió: >> This patch isn't acceptable because va_copy() isn't portable. >> >> I'm kinda wondering why PLy_printf and the functions after it even >> exist. They look like rather poorly done reimplementations of >> functionality that exists elsewhere in the backend (eg, stringinfo.c). >> In particular, why malloc and not palloc? > See attached patch. > I didn't bother to change the PLy_malloc and friends because I think > that would be too much change for 8.3. PLy_realloc is gone though > because there are no callers left after this patch. Yeah, that is about what I was thinking too. Are you set up to back-patch this as far as 7.3? If so, please apply. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

Alvaro Herrera <alvherre@alvh.no-ip.org> writes: > What I'm going to do is commit the fix to just 7.4 onwards. Fair enough. 7.3 is on life support anyway --- I'm not in favor of heroic efforts to port patches that far back. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings

"Marko Kreen" <markokr@gmail.com> writes: > Just a note - appendStringInfoVA should take *nprinted argument. Why? I can't imagine any real use for it. If you're thinking that it could provide a guide as to what to resize the buffer to, think again. regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Marko Kreen" <markokr@gmail.com> writes: > On 11/23/07, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> Why? I can't imagine any real use for it. If you're thinking that >> it could provide a guide as to what to resize the buffer to, think >> again. > If the output was truncated due to this limit then the return > value is the number of characters (not including the trailing > '\0') which would have been written to the final string if > enough space had been available. > What problem do you see? The problem is that you are quoting from some particular system's manual, and not any kind of standard ... much less any standard that every platform we support follows. The real-world situation is that we are lucky to be able to tell vsnprintf success from failure at all :-( regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend

"Marko Kreen" <markokr@gmail.com> writes: > Actually, the meaning could be changed to *needmore > and compensated inside function: How's that different from the existing function result? regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 6: explain analyze is your friend