Segmentation fault when in shared object

Discussion in 'C Programming' started by micro.q@gmail.com, Sep 17, 2012.

  1. Guest

    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
    , Sep 17, 2012
    #1
    1. Advertising

  2. Guest

    Op maandag 17 september 2012 16:29:36 UTC+2 schreef 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)
    , Sep 18, 2012
    #2
    1. Advertising

  3. 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-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.
    Johann Klammer, Sep 18, 2012
    #3
  4. 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.
    Ben Bacarisse, Sep 18, 2012
    #4
  5. Noob Guest

    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.
    Noob, Sep 18, 2012
    #5
  6. Kaz Kylheku Guest

    On 2012-09-18, Johann Klammer <1.net> wrote:
    > 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?


    !
    Kaz Kylheku, Sep 18, 2012
    #6
  7. Kaz Kylheku wrote:
    > On 2012-09-18, Johann Klammer<1.net> wrote:
    >> 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
    Johann Klammer, Sep 18, 2012
    #7
  8. Kaz Kylheku Guest

    On 2012-09-17, <> 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-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.
    Kaz Kylheku, Sep 18, 2012
    #8
  9. Ben Bacarisse <> 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) <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"
    Keith Thompson, Sep 18, 2012
    #9
  10. Keith Thompson <> writes:

    > Ben Bacarisse <> 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.
    Ben Bacarisse, Sep 18, 2012
    #10
  11. Kaz Kylheku <> writes:

    > On 2012-09-17, <> wrote:

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


    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.

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

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


    --
    Ben.
    Ben Bacarisse, Sep 18, 2012
    #11
  12. Guest

    Op maandag 17 september 2012 16:29:36 UTC+2 schreef 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!
    , Sep 19, 2012
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Alex Hunsley
    Replies:
    17
    Views:
    851
  2. Pud
    Replies:
    0
    Views:
    563
  3. Joel
    Replies:
    4
    Views:
    9,243
    John Harrison
    Oct 11, 2004
  4. Douglass Turner
    Replies:
    2
    Views:
    2,015
    Manfred Bartz
    Sep 4, 2003
  5. ChristophK
    Replies:
    8
    Views:
    317
    ChristophK
    Feb 24, 2006
Loading...

Share This Page