Segmentation fault when in shared object

[micro.q]

Hello,

I have a piece of code what handles a serial device. I made a test program which get a number of the serial port. When I use these same code in a shared object I get a segmentation fault on the serial functions tcgetattr of tcsetattr. I've verified that with gdb. The shared object is used by net-snmp.

My serial code is almost similar to http://code.google.com/p/as3-arduin...se/trunk/native-extension/Windows-x86/rs232.c
I've only changed to get it working with parity.

Because the code is working as executable I think it has something to do with the rights the application has to write to the settings.

Joram

 

[micro.q]

Op maandag 17 september 2012 16:29:36 UTC+2 schreef (e-mail address removed) het volgende:

Hello,



I have a piece of code what handles a serial device. I made a test program which get a number of the serial port. When I use these same code in a shared object I get a segmentation fault on the serial functions tcgetattr oftcsetattr. I've verified that with gdb. The shared object is used by net-snmp.



My serial code is almost similar to http://code.google.com/p/as3-arduin...se/trunk/native-extension/Windows-x86/rs232.c

I've only changed to get it working with parity.



Because the code is working as executable I think it has something to do with the rights the application has to write to the settings.



Joram

I've made some test code with only the necessary code. Here it is for download:
http://dl.dropbox.com/u/19997801/code.zip

LibTest
"make" to create libTest.so shared object
"make test" to create executable which handles the serial port directly(this one is working)

TestLib
"make" to create executable which loads libTest.so(this gives a segmentation fault)

 

[Johann Klammer]

Hello,

I have a piece of code what handles a serial device. I made a test program which get a number of the serial port. When I use these same code in a shared object I get a segmentation fault on the serial functions tcgetattr of tcsetattr. I've verified that with gdb. The shared object is used by net-snmp.

My serial code is almost similar to http://code.google.com/p/as3-arduin...se/trunk/native-extension/Windows-x86/rs232.c
I've only changed to get it working with parity.

Because the code is working as executable I think it has something to do with the rights the application has to write to the settings.

Joram

Did you try strace and gdb yet? If it is some trivial bug, it will show
up right away. I do not think, anyone here will want to do this for
you... Also, most people seem to filter out news from google groups, sou
you might be more successful posting questions, if you used a different
newsclient.

 

[Ben Bacarisse]

I've made some test code with only the necessary code. Here it is for
download: http://dl.dropbox.com/u/19997801/code.zip

Full marks for making a small test case. However... it does not compile
for me but the reasons are off-topic here.

LibTest
"make" to create libTest.so shared object
"make test" to create executable which handles the serial port
directly(this one is working)

TestLib
"make" to create executable which loads libTest.so(this gives a
segmentation fault)

There seems to be no C issue on the code (it's short enough to review a
few minutes) so the problem is most likely something very specific to
your system. comp.unix.programming is the place to ask.

 

[Noob]

I have a piece of code what handles a serial device. I made a test
program which get a number of the serial port. When I use these same
code in a shared object I get a segmentation fault on the serial
functions tcgetattr of tcsetattr. I've verified that with gdb. The
shared object is used by net-snmp.

The chaps in comp.arch.embedded might be able to help you.

 

[Kaz Kylheku]

shared object I get a segmentation fault on the serial functions tcgetattr
of tcsetattr. I've verified that with gdb. The shared object is used by

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[...]

Did you try strace and gdb yet?

!

 

[Johann Klammer]

shared object I get a segmentation fault on the serial functions tcgetattr
of tcsetattr. I've verified that with gdb. The shared object is used by

^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[...]

Did you try strace and gdb yet?

!

oops... getting senile

 

[Kaz Kylheku]

Hello,

I have a piece of code what handles a serial device. I made a test program
which get a number of the serial port. When I use these same code in a shared
object I get a segmentation fault on the serial functions tcgetattr of
tcsetattr. I've verified that with gdb. The shared object is used by
net-snmp.

My serial code is almost similar to http://code.google.com/p/as3-arduin...se/trunk/native-extension/Windows-x86/rs232.c
I've only changed to get it working with parity.

Because the code is working as executable I think it has something to do with
the rights the application has to write to the settings.

This is incorrect reasoning. Because the code works without dynamic shared
library loading, I would think that it has absolutely nothing to do with
permissions on the tty.

When X works, but X* doesn't, usually the fault is attributable to whatever
has changed between X and X*, not whatever is common.

The difference is either directly responsible for the problem, or
somehow reveals a latent problem. In this case, the difference is in the
dynamic linking. Whether or not you're using dynamic linking isn't going
to have an effect on the tty accessibility.

You also don't understand your gdb. When you get a segfault "on" the
tgetattr function, it's actually a fault in the line of code which calls the
function, not inside the function itself.

What's causing the problem in your code is that you named a global variable
"error". This is the name of a function in the GNU C library. (You might even
have a man page on this: man error).

This is like if you had an "int printf;" or "int fcntl;" variable.

Try putting the statement "error = 0" as the first statement of your
OpenComport and see where the segfault is now.

 

[Keith Thompson]

There seems to be no C issue on the code (it's short enough to review a
few minutes) so the problem is most likely something very specific to
your system. comp.unix.programming is the place to ask.

It's comp.unix.programmer.

 

[Ben Bacarisse]

It's comp.unix.programmer.

Silly. Thanks. The OP found it none the less and had an answer within
two hours.

 

[Ben Bacarisse]

On 2012-09-17, (e-mail address removed) <[email protected]> wrote:

This is incorrect reasoning. Because the code works without dynamic shared
library loading, I would think that it has absolutely nothing to do with
permissions on the tty.

When X works, but X* doesn't, usually the fault is attributable to whatever
has changed between X and X*, not whatever is common.

That's a good point to make but I don't think you follow it through.

The difference is either directly responsible for the problem, or
somehow reveals a latent problem. In this case, the difference is in the
dynamic linking. Whether or not you're using dynamic linking isn't going
to have an effect on the tty accessibility.

What's causing the problem in your code is that you named a global variable
"error". This is the name of a function in the GNU C library. (You might even
have a man page on this: man error).

That can't be the whole cause because it doesn't depend on "whatever
has changed between X and X*". The OP has that same variable in the
statically linked case and both of the dynamically linked cases, but
only one of those three fails.

This is like if you had an "int printf;" or "int fcntl;" variable.

Which is perfectly fine, this being comp.lang.c. The question for
comp.unix.programmer is why it becomes a problem when using dlopen.

 

[micro.q]

Op maandag 17 september 2012 16:29:36 UTC+2 schreef (e-mail address removed) het volgende:

Hello,



I have a piece of code what handles a serial device. I made a test program which get a number of the serial port. When I use these same code in a shared object I get a segmentation fault on the serial functions tcgetattr oftcsetattr. I've verified that with gdb. The shared object is used by net-snmp.



My serial code is almost similar to http://code.google.com/p/as3-arduin...se/trunk/native-extension/Windows-x86/rs232.c

I've only changed to get it working with parity.



Because the code is working as executable I think it has something to do with the rights the application has to write to the settings.



Joram

Thank you all for helping!