Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Native Development

Posts: 18
Registered: ‎07-05-2012
My Device: PlayBook
My Carrier: None

SIGSEGV on PlayBook. Help me, please!

Hi all!

Sorry for my bad English.

I am running my application on the my PlayBook and after several minutes intensivity work with graphics SIGSEGV here.

Application developed with C (only C, not C++). PB OS version I am using QNX Momentics IDE.

Where are core dump in PlayBook? How to get it?
How to find the point of generating SIGSEGV in my code?

Posts: 1,807
Registered: ‎04-28-2009
My Device: Z10 (STL100-4)-, Z10 (STL100-3)-, Z30 (STA100-5)-, Passport (SQW100-1)-, PlayBook (16GB)-
My Carrier: Verizon

Re: SIGSEGV on PlayBook. Help me, please!

If you wrote the application, you can debug the app with the Memeory Analysis tool which should help you find the SIGSEGV.

I don't think we have access to the core dump.
---Spends time in #blackberrydev on freenode (IRC)----
Three simple rules:
1. Please use the search bar before making new posts.
2. "Like" posts that you find helpful.
3. If a solution has been found for your post, mark it as solved.
--I code too much. Well, too bad.
Posts: 18
Registered: ‎07-05-2012
My Device: PlayBook
My Carrier: None

Re: SIGSEGV on PlayBook. Help me, please!

Thanks, for your answer.

I know that the problem with variables (not initialized and / or NULL). But I do not know where exactly.
The application developed by other developer. I am do bugfixing only.

I've used Memory Analysis and Application Profiler with IDE. Debuger shown me several points in not my libs.

For example:

Cannot access memory at address 0x0
No source available for "0x7807f6d8"


7807f6d4:   ldr r0, [r2, #8]
7807f6d8:   ldr r1, [r3, #4]
7807f6dc:   mov r2, r6


For each time an error is different.

For examle, next run:

No source available for "ConnectClientInfoExt() at 0x1e3c680"


01e3c678:   svc 0x00000000
01e3c67c:   pop {pc}
01e3c680:   pop {lr}
01e3c684:   b 0x1e14e7c


I dont know how to trace the call stack without dump. Available only the memory address and a string in assembler.

P.S. I've googled this a long time and not successful.

Posts: 499
Registered: ‎05-07-2012
My Device: developer
My Carrier: developer

Re: SIGSEGV on PlayBook. Help me, please!

I am not working directly with playbook or NDK 2 so there may be tricks I don't know.

But in general, memory issues can be difficult to track down, especially if the symptom "moves" from run to run.

I have not worked with core dumps but I thought they were available.  If you are lucky this would tell you where the issue lies.  However, more likely the actual bug causes a delayed effect and by the time you get to the core file the stack is too corrupted to be useful.


Are you able to run the app in the debugger?  Perhaps the debugger can provide more info where you crash.


Do you have some idea of where in the code the problem might lie, or what you do in the app to cause the issue? Does it happen when the app is sitting idle, or only after you do some specific activity?  Adding some qDebug() or other logging can assist in narrowing down where the real problem lies.  Once you develop an intuition for where the problem might be, you can be lucky and find it on code inspection.


Is this C++?   I'd be looking for:

- compiler warnings.  The compiler might already be telling you where the bug is

- uninitialized member variables in constructors

- pointers initialized by calls to routines that can return 0, but then assumed to succeed.  If the code you are using is properly productized, there may already be some logging built in; do your logs show an error?

- objects that are deleted (e.g. go out of scope) then used.

- if malloc or calloc is used, memory overrun or used after freed or size out by one.

- threading issues


So I wouldn't abandon looking at core files, but my approach would be, in order:

- run in debug to see if I can catch it

- check if my build logs are clear

- check if I have any errors in my application log

- narrow down what activity I do that causes the bug to show up

- use qDebug() or just intuition to narrow it down further

- code inspection of suspect code for the usual bugs (listed above)

- if still stuck, use a thorough memory checker. (You've already done a pass of this).


Some might quibble on my sequence.  But you need to try a breadth of approaches.


Good luck!



Posts: 1,068
Registered: ‎11-24-2011
My Device: PlayBook
My Carrier: x

Re: SIGSEGV on PlayBook. Help me, please!

In short: run it using debugger and when it crashes you'll have all function calls history.