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.

EM335X EVM linux: Can't debug inside a pthread.

I'm cross compiling from a linux host, building an application to run on my EM335x EVM.  I'm unable to use the debugger to set breakpoints or pause inside a pthread. When I set a breakpoint it works the first time but the second time it would hit the breakpoint the app is out to lunch.  If I let the thread run and try to Suspend the application it doesn't stop and I can no long control anything.

Any pthread based application I try to make exhibits this problem.  I confirmed that running the a work loop that fails in a thread from main works as expected.

I have confirmed that all my host side tools are up to date and I built and debugged my app in a new project, in a new workspace and still have the same issues.

Any thoughts on why I can't stop in a thread?

Host: Ubuntu 12.04 in VMware Player (on windows 7)

Target: ti-sdk-am335x-evm-07.00.00.00 (Arago 2013.12 am335x-evm) netbooting from the above VM.

Tools: Code Composer Studio:  Version: 6.1.0.00104

Minimal project that has this problem is attached and source is pasted in:

debugIntoThread.tar.gz

/*
 * debugFails.c
 *
 * This application is not pausable in the the thread.
 *
 *  Created on: May 5, 2015
 *      Author: user
 */


#include <sys/eventfd.h>

#include <pthread.h>
#include <stdio.h>

#include <time.h>
#include <errno.h>

#include <stdint.h>


// The call to nanosleep doesn't cause or prevent the problem, it's here simply
// to keep the message from flooding the console.
void delay(uint16_t msDelay) {
	struct timespec request;

	request.tv_sec = msDelay / 1000;
	request.tv_nsec = (msDelay % 1000) * 1000000L;

	while (( nanosleep( &request, &request ) == -1 ) && ( errno == EINTR )) {
		continue;
	}
}

void *PrintHello(void *threadid)
{
	for (;;) {
		printf("Hi guys.\n");

		// setting a breakpoint on this line will stop the first time but will
		// be a problem the second time it tries to stop.
		delay(1000);
	}

	return 0;
}

// #define DONT_FAIL
int main (int argc, char *argv[])
{
#if defined DONT_FAIL
	printf("Not a problem.\n");
	for (;;) {
		printf("Hi guys.\n");

		delay(1000);
	}
#endif

	printf("Going to have a problem.\n");
	pthread_t thread;
	int rc;

	printf("In main: creating thread\n");
	rc = pthread_create(&thread, 0, PrintHello, 0);
	if (rc){
		printf("ERROR; return code from pthread_create() is %d\n", rc);
	}

	pthread_exit(0);
}

  • Hi,

    Sorry for the delay in the reply;

    I suspect this issue is closely related to GDB itself instead of CCS.

    One of the reasons for my suspicion is that, when debugging Linux executables, the Eclipse open-source debugger (included with CCS) only acts as an interface that sends plain text GDB commands to the GDB server. If you want to double-check how the commands are being sent to the GDB server, once in a debug session you can highlight the Console view, click on the small arrow right beside its monitor icon and select the gdb traces view. It will show all the commands sent to the GDB.

    Another reason is that the breakpoint is reached in the first time - i.e., it seems the break command was set properly by the IDE but something either on the application or on GDB caused it to lose control.

    Therefore in this case I would strongly suggest you to check your application or even remove the IDE from the picture - i.e., by running GDB from command-line in an attempt to better isolate the problem.

    Hope this helps,
    Rafael
  • I have to admit I was hoping for a "oh yeah, we've seen that before, you just need to..." kind of response.

    It does seem unlikely that this is a widespread problem but I am using devkit and tools straight from TI with the only change from factory defaults that I can think of is that I'm netbooting from my VM. Can you confirm that you are or are not seeing this problem?

    If you are not seeing it do you have a process for getting me back to 100% factory defaults? I have 0 experience with using GDB directly and feel like I'm going to end up spending significantly more time trying to learn GDB and then figure what's wrong than just taking everything back to the defaults.

    Perhaps I should post this question over on the Linux Forum, or for continuity, could and should one of the moderators move it? 

    Thanks.

  • Rob,
    If you have not already done so, yes posting in the Linux Forum is probably your best bet. We do not really support GDB in this forum. Sorry.

    ki