[HACKERS] Re: 7.1 on DEC/Alpha

[Brent Verner]

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

[HACKERS] Re: 7.1 on DEC/Alpha

[Brent Verner]

here's a post-mortem.

#0  0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0, 
econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096
#1  0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, 
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234
#2  0x1200cdd74 in ExecEvalFuncArgs (fcache=0x14016aa70, argList=0x14016a030, 
econtext=0x14016a030) at execQual.c:603
#3  0x1200cde54 in ExecMakeFunctionResult (fcache=0x14016aa70, 
arguments=0x1401616d0, econtext=0x14016a030, isNull=0x11fffdf88 "", 
isDone=0x0) at execQual.c:654
#4  0x1200ce224 in ExecEvalOper (opClause=0x1401615f0, econtext=0x14016a030, 
isNull=0x11fffdf88 "", isDone=0x0) at execQual.c:841
#5  0x1200cea24 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, 
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1204
#6  0x1200cec54 in ExecQual (qual=0x14016a1a0, econtext=0x14016a030)
at execQual.c:1356
#7  0x1200cf2a8 in ExecScan (node=0x14016a1d0, accessMtd=0x1200d8320 SeqNext)
at execScan.c:129
#8  0x1200d846c in ExecSeqScan (node=0x1401615f0) at nodeSeqscan.c:138
#9  0x1200cc280 in ExecProcNode (node=0x14016a1d0, parent=0x14016a1d0)
at execProcnode.c:284
#10 0x1200ca8c0 in ExecutePlan (estate=0x14016a310, plan=0x14016a1d0, 
numberTuples=1, direction=ForwardScanDirection, destfunc=0x140020c20)
at execMain.c:959
#11 0x1200c9b50 in ExecutorRun (queryDesc=0x1401615f0, estate=0x14016a310, 
count=0) at execMain.c:199
#12 0x1200d1140 in postquel_getnext (es=0x140160630) at functions.c:324
#13 0x1200d1300 in postquel_execute (es=0x140160630, fcinfo=0x1401604a0, 
fcache=0x140160590) at functions.c:417
#14 0x1200d14d8 in fmgr_sql (fcinfo=0x1401604a0) at functions.c:542
#15 0x1200ce09c in ExecMakeFunctionResult (fcache=0x140160480, 
arguments=0x14015e810, econtext=0x140119cd0, isNull=0x140160350 "", 
isDone=0x11fffe258) at execQual.c:712
#16 0x1200ce2c4 in ExecEvalFunc (funcClause=0x1401615f0, econtext=0x140119cd0, 
isNull=0x140160350 "", isDone=0x11fffe258) at execQual.c:883
#17 0x1200cea3c in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, 
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1208
#18 0x1200c8e10 in ExecEvalIter (iterNode=0x1401615f0, econtext=0x14016a030, 
isNull=0x1 Error reading address 0x1: Invalid argument, isDone=0x0)
at execFlatten.c:56
#19 0x1200ce9b0 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, 
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1183
#20 0x1200cdd74 in ExecEvalFuncArgs (fcache=0x140160290, argList=0x14016a030, 
econtext=0x140119cd0) at execQual.c:603
#21 0x1200cde54 in ExecMakeFunctionResult (fcache=0x140160290, 
arguments=0x14015e840, econtext=0x140119cd0, isNull=0x11fffe3a0 "", 
isDone=0x11fffe468) at execQual.c:654
#22 0x1200ce2c4 in ExecEvalFunc (funcClause=0x1401615f0, econtext=0x140119cd0, 
isNull=0x11fffe3a0 "", isDone=0x11fffe468) at execQual.c:883
#23 0x1200cea3c in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, 
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1208
#24 0x1200ce574 in ExecEvalFieldSelect (fselect=0x14015e720, 
econtext=0x14016a030, isNull=0x11fffe3a0 "", isDone=0x0) at execQual.c:1091
#25 0x1200ceafc in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, 
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1234
#26 0x1200c8e10 in ExecEvalIter (iterNode=0x1401615f0, econtext=0x14016a030, 
isNull=0x1 Error reading address 0x1: Invalid argument, isDone=0x0)
at execFlatten.c:56
#27 0x1200ce9b0 in ExecEvalExpr (expression=0x1401615f0, econtext=0x0, 
isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1183
#28 0x1200ceea4 in ExecTargetList (targetlist=0x14015e870, 
targettype=0x14016, values=0x140160260, econtext=0x140119cd0, 
isDone=0x11fffe5a8) at execQual.c:1528
#29 0x1200cf1a8 in ExecProject (projInfo=0x0, isDone=0x1) at execQual.c:1751
#30 0x1200d8074 in ExecResult (node=0x14015e5b0) at nodeResult.c:167
#31 0x1200cc238 in ExecProcNode (node=0x14015e5b0, parent=0x14015e5b0)
at execProcnode.c:272
#32 0x1200ca8c0 in ExecutePlan (estate=0x14015eab0, plan=0x14015e5b0, 
numberTuples=0, direction=ForwardScanDirection, destfunc=0x1401603a0)
at execMain.c:959
#33 0x1200c9b50 in ExecutorRun (queryDesc=0x1401615f0, estate=0x14015eab0, 
count=0) at execMain.c:199
#34 0x12013e5c0 in ProcessQuery (parsetree=0x14015ea80, plan=0x14016)
at pquery.c:305
#35 0x12013c568 in pg_exec_query_string (
query_string=0x140115310 "SELECT p.hobbies.equipment.name, p.hobbies.name, p.name 
FROM person* p;", parse_context=0x1400c5c60) at postgres.c:817
#36 0x12013dd10 in PostgresMain (argv=0x11fffe9a8, real_argv=0x11ae8, 
username=0x1400b72f9 "pgadmin") at postgres.c:1827
#37 0x12011aef0 in DoBackend (port=0x1400b7080) at postmaster.c:2021
#38 0x12011a888 in BackendStartup (port=0x1400b7080) at postmaster.c:1798
#39 0x12011938c in ServerLoop () at postmaster.c:957
#40 0x120118c10 in PostmasterMain 

Re: [HACKERS] Re: 7.1 on DEC/Alpha

[Tom Lane]

Brent Verner [EMAIL PROTECTED] writes:
 here's a post-mortem.

 #0  0x1200ce58c in ExecEvalFieldSelect (fselect=0x1401615c0, 
 econtext=0x14016a030, isNull=0x14016ab31 "", isDone=0x0) at execQual.c:1096

Looks reasonable as far as it goes.  Evidently the crash is in the
heap_getattr macro call at line 1096 of src/backend/executor/execQual.c.
We need to look at the data structures that macro uses.
What do you get from

p *fselect

p *econtext

p *resSlot-val

p *resSlot-ttc_tupleDescriptor

BTW, if you didn't configure with --enable-cassert, it'd be a good idea
to go back and try it that way...

regards, tom lane

[HACKERS] Re: 7.1 on DEC/Alpha

[Brent Verner]

On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote:

observation:

  commenting out the queries with 'FROM person* p' causes the misc
  regression test to pass.

SELECT p.name, p.hobbies.name FROM person* p;

  Brent

| Hi,
|   I saw the thread from a few days ago about Linux/Alpha and 7.1. I
| believe I'm seeing the same problems with DEC/Alpha (Tru64Unix 4.0D).
| 
| I noticed the following in the postmaster.log, which occurs, as the
| Linux/Alpha bug report states, during the misc regression test.
| 
|   DEBUG:  copy: line 293, XLogWrite: had to create new log file - you probably 
|should do checkpoints more often
|   Server process (pid 24954) exited with status 139 at Fri Dec 22 17:15:48 2000
|   Terminating any active server processes...
|   Server processes were terminated at Fri Dec 22 17:15:48 2000
|   Reinitializing shared memory and semaphores
|   DEBUG:  starting up
|   DEBUG:  database system was interrupted at 2000-12-22 17:15:47
|   DEBUG:  CheckPoint record at (0, 316624)
|   DEBUG:  Redo record at (0, 316624); Undo record at (0, 0); Shutdown TRUE
| 
| the full src/test/regress/log/postmaster.log can be snagged from
| http://www.rcfile.org/postmaster.log
| 
| in addition to this, compiling on DEC/Alpha with gcc does not work,
| without some shameful hackery :) as __INTERLOCKED_TESTBITSS_QUAD() is 
| a builtin that gcc does not know about. The DEC cc builds pg properly.
| either way pg is built the test results are much the same, esp the
| FAILURE of misc regression test.
| 
| If there is anything else I can do to help get this working, please
| let me know.
| 
|   Brent Verner

[HACKERS] Re: 7.1 on DEC/Alpha

[Brent Verner]

On 22 Dec 2000 at 21:58 (-0500), Brent Verner wrote:
| On 22 Dec 2000 at 20:27 (-0500), Brent Verner wrote:
| 
| observation:
| 
|   commenting out the queries with 'FROM person* p' causes the misc
|   regression test to pass.

that's not what I meant to say. the misc test still FAILS, but it 
no longer causes pg to die.

  b