segfault generating runtime/parrot/include/config.fpmc Revision 35610 on linux

[theckman]

I've just temporarily applied an equivalent patch to packfilefixupentry.pmc, in the hopes that it will make tomorrow's release go more smoothly. In the meantime, this is still an issue and I'm worried that it points to something wrong in the parrot internals.

[jkeenan]

Tim,

I tried a slightly later SVN revision, r35614, also on Linux, and experienced no problems. Could you try again at HEAD to see if this was an error that was subsequently cleaned up?

Thank you very much.

[rurban]

Such segfaults are typically caused by an already installed parrot. Either shared libparrot or headers or binary. Or by a missing dependency: Check with ldd parrot

The patches at rt# 39742 installed-conflict solve this.

[theckman]

I tried with r35657 and continue to have the same issue.

Also tried checking out to a fresh directory and that did not resolve the issue.

As far as ldd, I'm not sure what I should be looking for.

[Infinoid]

Replying to theckman:

As far as ldd, I'm not sure what I should be looking for.

Well, just run "ldd parrot" and post the result here. What we're looking for is an instance of "libparrot.so" somewhere other than within your local build tree.

Mark

[TiMBuS]

I'm getting this error too, on a clean checkout of parrot r35662. Building on 64bit ubuntu 8.10. All optimizations are off. The stack trace after the segmentation fault is as follows:

#0  0x00007f4d43b78e3b in Parrot_cx_init_scheduler (interp=0x18b7080)
    at src/scheduler.c:83
#1  0x00007f4d43b3d0d7 in make_interpreter (parent=0x0, flags=0)
    at src/inter_create.c:264
#2  0x00007f4d43b1c10a in Parrot_new (parent=0x0) at src/embed.c:103
#3  0x0000000000400b5d in main (argc=2, argv=0x7fff4c392808) at src/main.c:52

[theckman]

My platform is also 64-bit ubuntu, but version 8.04 LTS

The segfault happens before parrot is built, but here is ldd miniparrot:

theckman@pegasus:~/code/parrot$ ldd miniparrot 
	linux-vdso.so.1 =>  (0x00007ffff0bfe000)
	libparrot.so.0.8.2 => /home/theckman/code/parrot/blib/lib/libparrot.so.0.8.2 (0x00007f88e801a000)
	libdl.so.2 => /lib/libdl.so.2 (0x00007f88e7e16000)
	libm.so.6 => /lib/libm.so.6 (0x00007f88e7b95000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x00007f88e7979000)
	libcrypt.so.1 => /lib/libcrypt.so.1 (0x00007f88e7741000)
	libcrypto.so.0.9.8 => /usr/lib/libcrypto.so.0.9.8 (0x00007f88e73c1000)
	libc.so.6 => /lib/libc.so.6 (0x00007f88e705f000)
	/lib64/ld-linux-x86-64.so.2 (0x00007f88e894a000)
	libz.so.1 => /usr/lib/libz.so.1 (0x00007f88e6e48000)
theckman@pegasus:~/code/parrot$ ldd parrot
ldd: ./parrot: No such file or directory
theckman@pegasus:~/code/parrot$ 

[TiMBuS]

Bugfix

[TiMBuS]

Got it working for me. Tracked it down using a whole lot of svn checking out and diffing.

In src/pmc/packfilefixupentry.pmc, the following method:

METHOD get_type()

Was simply declared in previous revisions as

INTVAL get_type()

I figure this was causing some kind of incorrect int size issue or.. something. I just altered it to

INTVAL METHOD get_type()

and it now works. Hope this helps.

[Infinoid]

Replying to TiMBuS:

In src/pmc/packfilefixupentry.pmc, the following method: {{{ METHOD get_type() }}} Was simply declared in previous revisions as {{{ INTVAL get_type() }}} I figure this was causing some kind of incorrect int size issue or.. something. I just altered it to {{{ INTVAL METHOD get_type() }}} and it now works. Hope this helps.

That's ... interesting. What your patch actually does is prevent the get_type() method from ever being implemented, as it no longer parses correctly. I don't know why this would cause segfaults in miniparrot, but I'll ask the list.

(As an aside, I can see I'm not testing .get_type() properly, as the patch doesn't trigger any test failures.)

[Infinoid]

Replying to TiMBuS:

Got it working for me. Tracked it down using a whole lot of svn checking out and diffing. In src/pmc/packfilefixupentry.pmc, the following method: {{{ METHOD get_type() }}} Was simply declared in previous revisions as {{{ INTVAL get_type() }}} I figure this was causing some kind of incorrect int size issue or.. something. I just altered it to {{{ INTVAL METHOD get_type() }}} and it now works. Hope this helps.