On Mon, 11 Aug 2008 00:41:30 +0100 (BST), John-Mark Bell wrote:
> 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.
Think I've got it:
Breakpoint 1, form_successful_controls (form=0x67b58d20,
submit_button=0x67b73968, successful_controls=0x67da67d8)
at render/form.c:257
257 if (!value) {
(gdb) p value
$1 = 0x0
(gdb) next
Current action: 0
BS 00000000
Current action: 0
BS 00000000
Current action: 0
trad_frame_addr_p: 1
trad_frame_realreg_p: 0
trad_frame_value_p: 0
alt 1
258 LOG(("failed to duplicate value"
(gdb) next
BS 00000000
Current action: 0
BS 00000000
Current action: 0
BS 00000000
Current action: 0
BS 00000000
Current action: 0
BS 00000000
Current action: 0
trad_frame_addr_p: 1
trad_frame_realreg_p: 0
trad_frame_value_p: 0
alt 1
492 warn_user("NoMemory", 0);
> 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..
Appears to be UTF8_CONVERT_OK all through that function AFAICT.
Chris
