DM8168: gdb & toolchain

Hi all,
I managed to reproduce the same issue with the mcfw-demo applications.
If a SEGV occurs in demo 1, no core dump is generated and using gdbserver/gdb is useless too (signal is not "delivered" to gdb in the host machine).

I set "ulimit -c unlimited" before launching the application.
I forced a SIGSEGV in demo_vcap_venc_vdec_vdis_bits_rdwr.c function VcapVencVdecVdis_ipcBitsProcessFullBufs:
           ...

          Venc_getBitstreamBuffer(&fullBufList, 0);
          int *x = 0;
          *x = 1;

          for (i = 0; i < fullBufList.numBufs; i++)
          ...


Thanks for any help!

Ivan

gdb in the 2009 toolchain is broken.  You need to update to 2010:

https://sourcery.mentor.com/sgpp/lite/arm/portal/release1600

Lee

Hi all,

I recompiled _every_ piece of software (kernel, the entire rdk, root fs...) with the new toolchain 2010.09-50 but I keep having troubles with SEGV and core dump file.

I have done a few tests and, as far as I understand, the situation is:

•   as far as the SEGV is forced __before__ calling Vsys_create() everything is fine: the process dies and a core dump is generated ("ulimit -a unlimited" is set)
•   if the SEGV is generated (int *x = 0; *x = 1;) __after__ calling Vsys_create() the situation is not understandable:

• the A8 process (dvr_rdk_demo_mcfw_api.out) DON'T die but remains in D state (uninterruptable state) and use 100% of the CPU (seen via top command)
• because of D-state, I'am not able to kill the process, of course
• the M3 processes keep on doing something; at least some debug strings are printed
• to recover the situation I am forced to reboot the machine (this is a bad thing but it is not my primary preoccupation right now)

Why a SEGV (with not explicit signal handler) doesn't force the process to die, and so to generate a useful core dump?

I have done the test with demo 1 and RDK 01.09.00.16.

Lee Holeva said:

gdb in the 2009 toolchain is broken.  You need to update to 2010:

https://sourcery.mentor.com/sgpp/lite/arm/portal/release1600

 

Lee

 

By the way, is there any "official" position by TI people about which toolchain should be used?

Thanks a lot!

Ivan

Ivan Nardi said:

Hi all,

I recompiled _every_ piece of software (kernel, the entire rdk, root fs...) with the new toolchain 2010.09-50 but I keep having troubles with SEGV and core dump file.

I have done a few tests and, as far as I understand, the situation is:

•   as far as the SEGV is forced __before__ calling Vsys_create() everything is fine: the process dies and a core dump is generated ("ulimit -a unlimited" is set)
•   if the SEGV is generated (int *x = 0; *x = 1;) __after__ calling Vsys_create() the situation is not understandable:

• the A8 process (dvr_rdk_demo_mcfw_api.out) DON'T die but remains in D state (uninterruptable state) and use 100% of the CPU (seen via top command)
• because of D-state, I'am not able to kill the process, of course
• the M3 processes keep on doing something; at least some debug strings are printed
• to recover the situation I am forced to reboot the machine (this is a bad thing but it is not my primary preoccupation right now)

Why a SEGV (with not explicit signal handler) doesn't force the process to die, and so to generate a useful core dump?

I have done the test with demo 1 and RDK 01.09.00.16.

Let me know if you need some further tests from me.

Thanks in advance

Ivan

Any news?

Ivan

Ivan Nardi said:

I have done the test with demo 1 and RDK 01.09.00.16.

Hi all,

Same issue with RDK version 01.09.00.19, too.

Any hope to have that issue solved in next GA version?

Thanks

Ivan

Hi Ivan,

I am also trying to debug RDK version 01.09.00.19 using gdb. Can you show me your building steps and setup step so I can try out over here.

Best regards,

Cheng

The problems mentioned on this post sound a lot like the problem's I have experienced, detailed here:  http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/716/t/162491.aspx#625197  

I believe the root of all these problems is that an OpenMax thread (or threads) is stuck in syslink code in the kernel, preventing signal delivery to the process. 

Could someone from TI please response to Ivan's question?  The DM814x EVM that we got recently shipped with a 2009 codesourcery tool chain.  Does TI need us to to stay there?

Hi all,

Same issue with RDK GA 02.00.00.23, too...

Ivan