64-bit: elf2app segmentation fault

[GoogleCodeExporter]

Don't know if this has to do with my switching to a 64-bit linux or what, 
but now I can't get the latest trunk to compile and elf2app throws seg 
faults.

Might have something to do with work being done on dingoo.o? No clue. I ran 
install twice as per one of the previous tickets with no change.

Attached are my install and AstroLander make outputs.

Original issue reported on code.google.com by russell.bernhardt@gmail.com on 12 Apr 2010 at 11:53

Attachments:

• dingoo_r95_install_output.txt
• astrolander_r95_make_output.txt

[GoogleCodeExporter]

Right, that seems to be a compatibility issue with the new elf2app, not sure 
why it
would segfault on linux but not windows when it uses entirely posix functions. 
You'll
have to revert to using the old elf2app for now until I can find out why it
segfaults, unless you want to look at it, it was late at night when I made it 
so it's
probably a silly error.

Original comment by Flatmush@googlemail.com on 13 Apr 2010 at 12:18

[GoogleCodeExporter]

OK, I've made a few changes that could possibly fix the segfault you're 
getting. Try
the new version, and if it segfaults again then uncomment all the printf's and 
tell
me what the output is, that should give me a rough indicator of the problem.

Original comment by Flatmush@googlemail.com on 13 Apr 2010 at 12:34

[GoogleCodeExporter]

Still not working... Attached the output from the uncommented printf's.

Original comment by russell.bernhardt@gmail.com on 13 Apr 2010 at 12:48

Attachments:

• elf2app_v96_output.txt

[GoogleCodeExporter]

OK, try again. I've fixed a few things that may have caused it, if it still 
segfaults
then can you also uncomment the printfs inside the _import and _export 
functions too.

Original comment by Flatmush@googlemail.com on 13 Apr 2010 at 12:35

[GoogleCodeExporter]

Original comment by Flatmush@googlemail.com on 13 Apr 2010 at 12:46

• Added labels: Priority-Critical
• Removed labels: Priority-High

[GoogleCodeExporter]

Original comment by Flatmush@googlemail.com on 13 Apr 2010 at 4:37

• Changed state: Started

[GoogleCodeExporter]

I'll test it this afternoon. I'm also downloading a 32-bit linux to test on it 
see if 
this is a 64-bit only issue or not. I'll follow up with what I find.

Original comment by russell.bernhardt@gmail.com on 13 Apr 2010 at 11:08

[GoogleCodeExporter]

Confirmed this is a 64-bit only issue. 32-bit linux compiles without a problem, 
but 
64-bit still seg faults on elf2app. Attached make output, but basically same 
results 
as before. Had already uncommented the _import and _export printf's.

I'll just stick to 32-bit linux for now for simplicity, but this should remain 
an open 
issue in case someone else attempt to report it.

Original comment by russell.bernhardt@gmail.com on 14 Apr 2010 at 6:16

• Changed title: 64-bit: elf2app segmentation fault

[GoogleCodeExporter]

Forgot to attach make output. Here it is.

Original comment by russell.bernhardt@gmail.com on 14 Apr 2010 at 6:22

Attachments:

• AstroLander_r107_make_output.txt

[GoogleCodeExporter]

Ok, I found out why it was breaking on a 64-bit system (I think). I was using
uintptr_t in some places instead of uint32_t (since it's a 32-bit app file). 
I've
corrected the issues and modified the printf/scanf calls to use the correct 
tokens.

Try this new one, and as always if it doesn't work post the output, but I 
suspect it
might work this time.

Original comment by Flatmush@googlemail.com on 14 Apr 2010 at 10:32

[GoogleCodeExporter]

Since it's only on 64-bit, this isn't quite so critical now, reduced priority 
to High.

Original comment by Flatmush@googlemail.com on 14 Apr 2010 at 10:33

• Added labels: Priority-High
• Removed labels: Priority-Critical

[GoogleCodeExporter]

Ready for some weirdness?

In $DINGOO_SDK/samples/AstroLander:

"../../tools/elf2app/elf2app AstroLander" works
"$DINGOO_SDK/tools/elf2app/elf2app AstroLander" seg faults

No idea what the deal with that is. Might be an OS issue, but something like:

"$MIPSTOOLS/bin/mipsel-linux-gcc" works just fine, so I don't think it's an 
environment variable resolution issue... but like I said, seems to be an OS 
issue as 
there should be no difference between:

"../../tools/elf2app/elf2app" and "$DINGOO_SDK/tools/elf2app/elf2app".

Strange. Dunno if you want to consider this "closed" or if you know what's 
going on.

In the meantime, I've modified my AstroLander Makefile to use a relative path 
instead 
of the variable path to elf2app and it seems to be working. I won't commit it 
as it 
seems to be an issue only on my 64-bit system. May be a good topic for a "known 
issues" wiki page.

For the record, I'm using Ubuntu 9.10 64-bit.

Original comment by russell.bernhardt@gmail.com on 14 Apr 2010 at 3:37

[GoogleCodeExporter]

I think it's something that can be fixed. I use the path passed into argv[0] to
calculate the current path, then use the known current path to load the import 
and
export tables. It could be a problem there, whereby the path passed into 
argv[0] is
literally what was typed at the commandline, and then fopen doesn't correctly 
resolve
environment variables.

Try replacing the fopen part of that with a popen and cat, cause that will 
resolve
environment variables, either that or we could make it resolve environment vars 
ourself.

Original comment by Flatmush@googlemail.com on 14 Apr 2010 at 7:11

[GoogleCodeExporter]

That's so lame! It's completely the OS's job to resolve environment variables 
IMO. Oh 
well. I'll mess with it later then, for now I got the Windows/Cygwin config 
going just 
because I got tired of rebooting; that and I can't access my Dingoo's internal 
memory 
from Linux.

Original comment by russell.bernhardt@gmail.com on 14 Apr 2010 at 7:48

[GoogleCodeExporter]

I wrote a quick test to make sure my OS is properly resolving environment 
variables 
and it seems to be working just fine. I wrote the attached parser to test it 
and in 
Cygwin and in 64-bit Linux the raw string is always parsed by the OS before 
it's 
passed to the application, so I don't think fopen is the issue. I'll continue 
looking 
at this and see if I can't trace the problem.

Original comment by russell.bernhardt@gmail.com on 18 Apr 2010 at 7:29

Attachments:

• parseenv.c

[GoogleCodeExporter]

one more bug found (see revision 207)
please test your cases

Original comment by djd...@gmail.com on 15 Jul 2010 at 5:56