Menu
Sites
Language
Application crashes instantly?

I'm running an application, but it appears to crash instantly. The logs say that it cannot attach to the process, and when running "native-debug", I get the error:

Cannot access memory at address 0x0
[Inferior 1 (process 12474) exited with code 0377]

Currently, I'm not able to see any "printf" log output, or AppLog output for that matter. I modified one of the sample applications to have an "int main", and it still ran properly. I was concerned this may be the problem. Interestingly, if I try to remove the "int main" from my our codebase, we have a linker error, that crt1.so is referencing main from the "start" method. This doesn't appear to be required in the sample, so I'm not sure if this is implied behavior from somewhere else, and if this may be the cause of some of our trouble?

Is there a place to get printf log output, and are there more details about the application start-up process using OSP, regarding main vs. OspMain, etc?

List

Responses

6 Replies
Pushpa G

Hi,

I ran sample apps available in IDE, it ran successfully in 2.2.1 emulator. I dint face the above issue and also AppLog("test") statements are getting printed.

Is this issue happening to you with all the sample apps or only in your app? If it sin your app, then attach your app here so that i can check it

Pushpa G

You can get/see the AppLog() output in the Log pane of the IDE . If Log pane is not seen in the IDE, then go to Window menu in the IDE->Show view>Log, then you can see it

Slawek Kowalski

Please open any sample project (File->New->Tizen Native project ->Sample) and then build project. It should work.

 

AppLog() doesn't print in Release mode. Make sure you have switched for Debug.

 

hgw7

'Cannot access memory' must be due to a dangling pointer. The pointer to arguments of the modified 'main' must be contaning garbage values. 0377 is the status code returned to the parent by a call to exit() in your program.
Also, what did  you modify in the sample program to change from 'Ospmain' to 'int main' ?

Joshua Granick

The OS doesn't provide a lot of indication why execution fails, but I've determined that the above error (or similar) occurs in multiple scenarios:

  • If you deploy an i386 executable to an ARM device
  • If you replace (but rename) the binary from one application, and package it in another
  • If you did something else wrong :(

It's curious that taking a valid executable from application, and packaging in another throws this error. Is this is somehow related to the "rpath" when building the binary, or is there any other reason why this is not supposed to work? Thanks

Joshua Granick

Progress!

We were not using "-pie" before. I believe it was this flag that removed the requirement for an "int main" entry point. Even though our tests with the Tizen sample applications were successful using an OspMain to call main, removing our main function now has fprintf output writing to /tmp.