So Python noob question, but here goes, I have issued the following
at a command prompt:

>python3 test_AES.py

and receive:

.python[13026]: segfault at ffffffffffffffff ip ffffffffffffffff sp 00007fffa2234778 error 14
Segmentation fault

My question is, can someone suggest how I would go about debugging where my problem is?

I have tried to use pdb but am not real familiar with options.
Please let me know if there is further detail required?

Cheers
Grail

I'm going to guess the issue isn't your python code, but rather the fact there is a mismatch between shared libraries somewhere. What modules does your script use?

hey mesius ... wasn't sure anyone was going to help on this one.

You are 100% correct about the shared libraries. I have converted (or in the process of) the Pycrypto module
to be Python3.X compatible. I am able to run my own small scripts using the likes of AES, Blowfish encryptions,
but i am receiving this segfault when I am trying to run the built in tests that came with it.

To make it simple I am happy to look at just one of the libraries and when pointed in the right direction
will tackle the others myself. To this end I have been trying to find a way to debug AES.so which was created as
part of the install. Are you able to help me understand the best way to debug this shared library?

I have added the -g option to the compilation and if I do a simple - gdb AES.so it tells me that it loads
all necessary symbols, but of course when I then run and backtrace I am not lead to any intelligible errors.

When searching on google it says that the best way to debug a shared library is to compile it into
another program, but the issue I have here is I would not know what sort of program to write to
illicit the correct outcome

Please let me know what sort of information I can provide to further this effort?

It's been awhile since I've debugged shared libraries - it can be tricky. Often times the problem isn't with the main library you are working with, but rather the problem is an compatibility with a library that is being depended on. So to see what libraries AES.so needs, use the 'ldd' command.

* ldd AES.so # should show you the libraries AES.so depends on.
* ldd -r AES.so # forces the loader to resolve all of the symbols - which will sniff out symbols that can't be found in any libraries.

By the way - make sure the libraries being found are the ones it should be finding. A common problem is that the loader grabs a version of a library out of /usr/lib instead of from your test area. You can use the LD_LIBRARY_PATH or SHLIB_PATH environment variables to give a list of paths to prefer over the default system paths, which are defined in /etc/ld.so.conf (usually).

-Rob

So ldd - AES.so gives:

I am assuming from this output that all the symbols have been found?

Yes - this means the loader was able to resolve all of the symbols.

This means the problem is a bit (actually, a lot) more subtle. Are you able to do very limited tests with the python script to see if it's possible to invoke the script without provoking the segfault? If so, try to map python code to functionality in the library you're porting. That will help get you "in the right neighborhood". Sorry I can't offer better advice than that... without the ability to poke and prod at this myself I can only offer some high-level advice.

-Rob

Hi Rob

Thanks for the input. Yes I am able to utilise the python code without invoking the segfault.
i was happily doing so until I tried to run the built in tests, which I am guessing are doing
things I haven't tried as yet
I will try as you have suggested and see how I go.

Cheers