On 24 Dec 2000 at 01:19 (-0500), Tom Lane wrote:
| Brent Verner <[EMAIL PROTECTED]> writes:
| > (gdb) p *resSlot
| > Error accessing memory address 0x40141830: Invalid argument.
| 
| Oooh.  resSlot has been truncated to 32 bits --- judging by the other
| nearby pointer values, it almost certainly should have been 0x140141830.
| Now we have a lead.

FWIW, saying 'set econtext->ecxt_param_list_info->value 0x14014183' in
geb allows the process to not SEGV where it _was_ destined to do so, 
though it does SEGV in a later return to the function. I've tried to
determine where this value is originating, and where it is subsequently
modified, but have not been able to do so. lost in gdb. 

Q: I tried doing 'watch <address>', but this (appeared) to just hang.
  is there some trick to using 'watch' on addresses that I might be
  overlooking?

| I am guessing that the truncation happened somewhere in
| executor/functions.c, but don't see it right away...

more observations WRT sql that blows up postgres on Alpha.

works:
  SELECT p.hobbies.equipment.name, p.hobbies.name, p.name 
    FROM ONLY person p;

breaks:
  SELECT p.hobbies.equipment.name, p.hobbies.name, p.name 
    FROM person p;
  SELECT p.hobbies.equipment.name, p.hobbies.name, p.name 
    FROM person* p;

whatever it is that ONLY causes, avoids the breakage. I've spent the
past two days in a gdb-hole, going in circles. I just think don't know 
enough (about gdb or postgres) to make any further progress. anyway, 
if someone could tell me what difference the ONLY keyword makes WRT
pg internally, it might help me quit running in circles.

thanks.
  brent

Reply via email to