Velocity Reviews

Velocity Reviews (http://www.velocityreviews.com/forums/index.php)
-   C Programming (http://www.velocityreviews.com/forums/f42-c-programming.html)
-   -   Segmentation fault when in shared object (http://www.velocityreviews.com/forums/t952304-segmentation-fault-when-in-shared-object.html)

micro.q@gmail.com 09-17-2012 02:29 PM

Segmentation fault when in shared object
 
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-arduino...ws-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@gmail.com 09-18-2012 07:58 AM

Re: Segmentation fault when in shared object
 
Op maandag 17 september 2012 16:29:36 UTC+2 schreef mic...@gmail.com 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-arduino...ws-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 09-18-2012 09:53 AM

Re: Segmentation fault when in shared object
 
micro.q@gmail.com wrote:
> 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-arduino...ws-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 09-18-2012 12:13 PM

Re: Segmentation fault when in shared object
 
micro.q@gmail.com writes:

> 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.

--
Ben.

Noob 09-18-2012 12:14 PM

Re: Segmentation fault when in shared object
 
micro.q wrote:

> 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 09-18-2012 05:06 PM

Re: Segmentation fault when in shared object
 
On 2012-09-18, Johann Klammer <klammerj@NOSPAM.a1.net> wrote:
> micro.q@gmail.com wrote:
>> 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 09-18-2012 05:07 PM

Re: Segmentation fault when in shared object
 
Kaz Kylheku wrote:
> On 2012-09-18, Johann Klammer<klammerj@NOSPAM.a1.net> wrote:
>> micro.q@gmail.com wrote:
>>> 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 09-18-2012 06:02 PM

Re: Segmentation fault when in shared object
 
On 2012-09-17, micro.q@gmail.com <micro.q@gmail.com> wrote:
> 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-arduino...ws-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 09-18-2012 06:59 PM

Re: Segmentation fault when in shared object
 
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
[...]
> 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.

--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Will write code for food.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Ben Bacarisse 09-18-2012 07:40 PM

Re: Segmentation fault when in shared object
 
Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> [...]
>> 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.


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

--
Ben.


All times are GMT. The time now is 09:50 PM.

Powered by vBulletin®. Copyright ©2000 - 2014, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.