...

disassemble 0x083b6fd0 0x083b6ff0

Henrik, I'm a newbie in that, and so where you found such values 0x083b6fd0 0x083b6ff0 ?

The values are a reasonable context around the address where it went wrong:

Program received signal SIGSEGV, Segmentation fault. 0x083b6fe5 in ?? () (gdb) bt #0 0x083b6fe5 in ?? ()

And here is a disass:

Somebody who knows IA32 assembler will have to look at it.

/ Henrik Grubbström (Lysator)

Previous text:

2002-10-08 17:39: Subject: more debug?

---

...

disassemble 0x083b6fd0 0x083b6ff0

Henrik, I'm a newbie in that, and so where you found such values 0x083b6fd0 0x083b6ff0 ?

And here is a disass:

(gdb) disassemble 0x083b6fd0 0x083b6ff0 Dump of assembler code from 0x83b6fd0 to 0x83b6ff0: 0x83b6fd0: xlat %ds:(%ebx) 0x83b6fd1: jp 0x83b6fca 0x83b6fd3: pusha 0x83b6fd4: loope 0x83b6f82 0x83b6fd6: mov %ecx,%edx 0x83b6fd8: mov $0xd2,%ch 0x83b6fda: in $0xe6,%al 0x83b6fdc: (bad) 0x83b6fdd: imul $0xffffffd0,%ss:0x2900d4a4(%eax),%ebx 0x83b6fe5: add %dl,(%eax) 0x83b6fe7: xor %bh,%bh 0x83b6fe9: std 0x83b6fea: movsb %ds:(%esi),%es:(%edi) 0x83b6feb: inc %esp 0x83b6fec: cltd 0x83b6fed: inc %esp 0x83b6fee: gs 0x83b6fef: ja 0x83b7057 End of assembler dump.

/ Honza (hop) Petrous

OK, EAX contains -1, but now I need to find out how such code can be located inside Pike binary.

(gdb) info all-reg eax 0xf7c68bde -137983010 ecx 0x40212128 1075913000 edx 0x8397428 137983016 ebx 0x8356054 137715796 esp 0xbffff8d8 0xbffff8d8 ebp 0xbffff8e8 0xbffff8e8 esi 0x2 2 edi 0xbffffa84 -1073743228 eip 0x83b6fe5 0x83b6fe5 eflags 0x10297 66199 cs 0x23 35 ss 0x2b 43 ds 0x2b 43 es 0x2b 43 fs 0x0 0 gs 0x7 7 st0 0 (raw 0x00000000000000000000) st1 0 (raw 0x00000000000000000000) st2 0 (raw 0x00000000000000000000) st3 0 (raw 0x00000000000000000000) st4 0 (raw 0x00000000000000000000) st5 0 (raw 0x00000000000000000000) st6 1 (raw 0x3fff8000000000000000) ---Type <return> to continue, or q <return> to quit--- st7 0 (raw 0x00000000000000000000) fctrl 0x37f 895 fstat 0x4000 16384 ftag 0xffff 65535 fiseg 0x23 35 fioff 0x80dada8 135114152 foseg 0x2b 43 fooff 0xbfffebb0 -1073747024 fop 0x55d 1373 xmm0 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm1 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm2 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm3 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm4 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm5 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm6 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} xmm7 {f = {0x0, 0x0, 0x0, 0x0}} {f = {0, 0, 0, 0}} mxcsr 0x0 0 orig_eax 0xffffffff -1 (gdb)

/ Honza (hop) Petrous

Previous text:

2002-10-08 18:13: Subject: more debug?

---

All the assembly before the offending instruction is useless, because it doesn't align with the start of the instructions properly (remember that IA32 instructions are variable length, so you can get any amount of crap disassembly from starting at a random address).

0x83b6fe5: add %dl,(%eax)

is the instruction causing the SEGV, so %eax contains an invalid address (info regs will reveal which one).

/ Marcus Comstedt (ACROSS) (Hail Ilpalazzo!)

Pike_interpreter.frame_pointer->pc should contain the start address in the assembler code.

/ Martin Stjernholm, Roxen IS

Previous text:

2002-10-08 21:45: Subject: more debug?

---

Try disassembling the bit before the offending instruction until you find a properly aligned starting instruction. A good rule of thumb is that if you get bad instructions "(bad)", i/o instructions (e.g. "in 0xe6,%al"), large adress offsets and/or strange segment overrides (e.g. "imul $0xffffffd0,%ss:0x2900d4a4(%eax),%ebx"), and similar strange thinks, you're either disassembling malaligned code, or 'extrons' of data inserted into the code (recognized by strange code that is never reached because the surrounding code always jumping around it).

You could also try stepping up into the next stack frame (which belonged to mega_apply) and see if any of the local variable values there give any hint of what module/class/valuetype was involved.

/ Leif Stensson, Lysator