Segmentation Fault

[null]

Hi,

I downloaded aescrypt for linux sources and managed to compile in Tiny Core Linux with no errors. When I try to execute an encryption,

# aescrypt -e Readme.txt

it prompts for password and re-enter password, then Segmentation Fault, with echo $0 = 139.

Any suggestions???

thanks in advance.

[paulej]

Do you have the ability to use gdb to get a stack trace?

Does the problem occur with every password, or perhaps just a certain sequence of characters?

The one problematic area in the Linux code is the use of the iconv libraries. There are known issues where certain non-ASCII characters are not converted properly. I've not heard of it causing a segmentation fault, but it does result in encrypted files that have the wrong password applied. (Works fine on Linux, but not cross-platform and not one day when we find a proper solution to the unicode problem.) Are you using any non-ASCII characters?

[null]

Thank you for the quick reply.

I am not using anything fancy for the password, just "1234", "123", etc to test things out. Also tried password123 just in case it was expecting longer passwords. But same result.

The thing is, I also compiled it on a very older version of fedora (Fed 6, uname -a ==> 2.6.18-1.2798.fc6)
and this worked fine.

I am not familiar with gdb anymore. I did note that it was complain about the iconv library when I typed wrong passwords in just to test it.

thanks again.

[null]

Ok,

I managed to get gdb running and backtrace the seg fault with the following result:

#0 0xb76e8ace in memset () from /lib/libc.so.6
#1 0x0804ae00 in main()

[null]

just an update.

Looks like it works with /lib/libc-2.7.so (or earlier). This was from slax.

But the one I was using in tinycore is libc-2.13.so, which resulted in Seg Fault. That was tinycore 4.1, I loaded tinycore 3.0 which had libc-2.10.so ??? but still Seg Faulted.

[paulej]

Since you compiled against the library, I'd expect it to work. It might be that there is a bug that only shows itself in that particular library. I'd like to find it, of course.

It appears it might be right in main(). There are 8 places where memset() is called. If you can insert a debug statement before each one (just a printf("memset 1\n"); or something), perhaps can figure out which particular memset call is failing. From there, we might be able to determine why.

[null]

Ok, did printf tracing. It was bombing out on the first memset in aescrypt.c/main() line 989.

the password entered was good, being "1234" was received properly into pass_input. However, passlen = -1 after returning from passwd_to_utf16 call (just straight before the memset call).

[paulej]

And there is, indeed, a bug right there. The memset should not use -1 as the length.

The good news is that we can easily fix this. The bad news is that the iconv routines are not working, which is why the value is set to -1. So, even if we fix the bug (which I'll put on the list), you'll have problems due to iconv. We really need to get a handle on the Unicode issue. People want to use characters outside of 0x20 - 0x7E.