• State Resolved
  • Locked Locked
  • Replies 3 replies
  • Subscribers 54 subscribers
  • Views 1260 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

GUI debug for Linux application?

Chuck Peplinski
Genius 5770 points
Other Parts Discussed in Thread: LM137

I posted this question to the Linux area, but found no response (http://e2e.ti.com/support/embedded/linux/f/354/t/155778.aspx#566644).  I guess it is really a CCS question, so I'll repost here.

I am trying to use the GUI debugger in CCS 5.1.  I am using the community Linux distributions.  I have a relatively simple Linux app running on an LM137 eval board.  So far it simply manipulates I2C and GPIO, all from user space.  It prints to the serial console.  It runs reasonably well when the debugger is not engaged.  But when I try to run it under the debugger (using gdbserver :10000), the serial console quickly ends with 

Child terminated with signal = 5

Child terminated with signal = 0x5 (SIGTRAP)
GDBserver exiting

The console window on CCS says

[New Thread 936]
Cannot access memory at address 0x0
Quit (expect signal SIGINT when the program is resumed)

This isn't obviously related to any action of my program. It takes the better part of a second to happen, and more or less of my program can run during that time.  The console print ends at different places. It's almost as if it happens a fixed number of seconds after startup.  I install my own sigint handler and it is not triggered.  Searching the community for sigint, I find a post about DSPBIOS installing handlers.  But I'm not using DSPBIOS, AFAIK.  

Does this sound familiar to anyone?   Is anyone having success using the CCS 5.1 GUI with a Linux application?  I suspect that some combination of module versions is not compatible, but I'd love to hear someone else say they've seen this, or they run a similar system without problems.

Chuck

  • 0
    TI__Guru**** 171349 points

    Chuck,

    I guess you are running on an OMAPL137, is that so? LM137 is a negative voltage regulator from the National Semiconductor product line...

    Unfortunately I never got this error before, therefore I can give only a few tips.

    From your description it seems the error is being caused by an invalid memory operation (rogue pointer, overrun of boundaries, etc), since GDB (on host side) is showing that a specific memory address is locked up.

    The issue may be either coming from the application or from the Gdbserver itself. I found some reports about bugs on gdbserver (here, for example)

    On the other hand, the fact the application runs fine without Gdbserver indicates the debugger is influencing its behaviour, but does not necessarily mean the application does not have a problem that throws this invalid memory access. One thing that comes to my mind is a possible a race condition that is only evidenced by the slower operation under Gdbserver.

    Therefore I would carefully inspect the traffic between GDB and Gdbserver (check the attached screen of this thread) and get some additional insight.

    Also, I found some interesting techniques to debug and track memory issues. Check some references here and here. Also, this long thread discusses some useful gdb commands that can be used to try to track down what is happening.

    I will get back to you if I can think of any possible scenarios that may be causing this.

    Hope this helps,

    Rafael

  • 0 in reply to desouza
    Genius 5770 points

    I've used my share of LM137's.  Must be burned into my brain.  Is your next more positive processor an L337?  :-)  

    The fact that this is not a common setup error gives me the direction I need to keep looking.  I've used memory debug tools before and that's a good idea.  Thanks for the excellent tips.  I'll keep you posted on what I find.

      Chuck

  • 0 in reply to Chuck Peplinski
    Genius 5770 points

    Thanks.  The answer was in http://e2e.ti.com/support/development_tools/code_composer_studio/f/81/t/138629.aspx#499882.

    Apparently the gdbserver in CodeSourcery 2009q3 is not multi-thread capable.   I updated my CodeSourcery version to the latest and now it is working.

    As an aside, I like this post on memory debuggers:

    http://www.ibm.com/developerworks/linux/library/l-debug/

    I noticed that strace didn't work in the community distribution, and I didn't get as far as looking for Electric Fence.  In a previous (no-Linux) project, we replaced malloc and free with instrumented versions and that sort of memory debugging was quite useful.  But that's not the problem here.

        Chuck