On Sun, 10 Aug 2008, Chris Young wrote:
On Sun, 10 Aug 2008 11:12:42 +0100 (BST), John-Mark Bell wrote:
Well, to get to that point, one of the instances of goto no_memory must
have been hit. The only way that can happen is if something failed and
returnet a NULL pointer. You can do print <varname> to print out the
current value of a variable. Also make sure you're building with -O0, as
optimisation can obfuscate things.
I've attached the output from gdb as I'm not really sure what I'm
looking for.
That output looks truly odd. For starters, "next" appears to be stepping
in to functions, where it should be stepping over them. Secondly, that
output goes no further than the str(n)dup call at the end of
form_acceptable_charset. form_acceptable_charset, however, will never
cause NoMemory to be reported to the user so the actual issue is well
after that.
As I've said before, you need to inspect the return values of any
function that causes form_successful_controls to do goto no_memory on
failure. That is, print out the variables being inspected at lines 257,
276, 296, 307, 323, 333, 355, 362, 380, 387, 420, 445, 456, 471, and 481
of form.c.
Your other email suggests that form_encode_item is causing the problems.
If so, you could break on that, instead, and step through looking for
err != UTF8_CONVERT_OK. Given how often the charset conversion routines
are used, it's somewhat surprising that they're failing in this case..
J.
