Re: strange path through code (initdb problem)

Started by Keith Parksover 27 years ago2 messageshackers
Jump to latest
#1Keith Parks
emkxp01@mtcc.demon.co.uk

Bruce Momjian <maillist@candle.pha.pa.us>

Are you compiling with optimization. Thay may do it.

Yes, and it does :-(

Compiled with -O0 everything works fine (well almost).
With -O2, the default, I get the SIGSEGV as before.

I seem to remember I had this optimisation problem some while
ago and someone, Thomas?, fixed it by rewriting some code.

So, for now I'm reasonably happy and can get on with some
testing.

Thanks,
Keith.

BTW: this is tested after Jan's fix for indexes. (Thanks Jan)

Show quoted text

Keith Parks

The latest changes do not seem to have fixed my problems
(assumed to be alignment)

What I find really strange is the path taken through the
code when stepping upto the SIGSEGV.

ie. how do we get to line 208 in heaptuple.c (the other half of
the if/else statement) without passing through line 203??

Remembering that we should never touch line 208 if the
attalign is 'd'

Puzzled,
Keith.

163 switch (att[i]->attlen)
(gdb)
195 if (att[i]->attlen < sizeof(int32))
(gdb)
198 if (att[i]->attalign == 'd')
(gdb)
200 data = (char *)
DOUBLEALIGN(data);
(gdb)
201 memmove(data,
DatumGetPointer(value[i]),
(gdb)
204 }
(gdb)
208 memmove(data,
DatumGetPointer(value[i]),
(gdb)

Program received signal SIGSEGV, Segmentation fault.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
+  If your life is a hard drive,     |  (610) 353-9879(w)
+  Christ can be your backup.        |  (610) 853-3000(h)
#2Bruce Momjian
bruce@momjian.us
In reply to: Keith Parks (#1)

Bruce Momjian <maillist@candle.pha.pa.us>

Are you compiling with optimization. Thay may do it.

Yes, and it does :-(

Compiled with -O0 everything works fine (well almost).
With -O2, the default, I get the SIGSEGV as before.

I seem to remember I had this optimisation problem some while
ago and someone, Thomas?, fixed it by rewriting some code.

So, for now I'm reasonably happy and can get on with some
testing.

If you can find out which file is the problem, we can probably fix it
without access to the machine.

You can compile everything with -O2, then change your optimization in
Makefile.custom to -O0. Go to psql/src/backend and 'cd' to a directory,
do a 'make clean', then a make,make install and test initdb. As soon as
it starts working, you have your directory. Or you could compile
everything with -O0 and start doing -O2 compiles until it breaks.

When you find the directory, find the file by recompiling one at a time.
Once you find the file, I think I can figure out what is wrong with the
file. I can go through the diff since 6.3.2, and see what has changed.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)