[ket]

Hi,

Looks like gdb cannot find the file for the frame, each of the frames below without the file defined cannot find the source file.

^done,stack=[frame={level="0",addr="0x08055cab",func="_ZN3Lib7ImgProc9CLightBar15DetectEdgesFastEPN6Camera10TImageInfoE"},frame={level="1",addr="0x08055b19",func="_ZN3Lib7ImgProc9CLightBar11DetectEdgesEPN6Camera10TImageInfoE"},frame={level="2",addr="0x0804b225",func="Application::WidthMonitor::CApplication_WidthMonitor::RunStateMachine",file="../Application/WidthMonitor/Src/Application_WidthMonitor.cpp",fullname="/tmp/VisualGDB/Archos/Application/WidthMonitor/Src/Application_WidthMonitor.cpp",line="115"},frame={level="3",addr="0x0804a6bd",func="_ZN11Application12CApplication10ThreadMainEv"},frame={level="4",addr="0x0804a63f",func="_ZN11Application12CApplication17ThreadMain_StaticEPv"},frame={level="5",addr="0x006c2e99",func="start_thread",file="pthread_create.c",fullname="/usr/src/debug/glibc-2.13-13-g943515f/nptl/pthread_create.c",line="301"},frame={level="6",addr="0x00608d2e",func="clone",file="../sysdeps/unix/sysv/linux/i386/clone.S",fullname="/usr/src/debug/glibc-2.13-13-g943515f/sysdeps/unix/sysv/linux/i386/clone.S",line="133"}]

Translated through c++filt, the mangled function names are (in order of appearance):

Lib::ImgProc::CLightBar::DetectEdgesFast(Camera::TImageInfo*), Lib::ImgProc::CLightBar::DetectEdges(Camera::TImageInfo*), Application::CApplication::ThreadMain(), Application::CApplication::ThreadMain_Static(void*)

.

Find out where these functions are defined and why those files were compiled without debugging symbols for GDB (GCC flag -ggdb). Then recompile them with debugging symbols to be able to set breakpoints in those files.

[ket]

Hi,

It is how gdb reports the string. While debugging if you change the view mode to ‘All GDB interaction’ in the GDB Session window and then hover over the variable, you will see what gdb replies as the variable value.

[ket]

Hi,

The hexadecimal mode applies only to individual characters not to the entire string, press on the ‘+’ in front of the response variable to see the hexadecimal vs decimal difference of individual characters.
The string view of a character array tries to translate the character values to letters and then assembles a string from them, that is why the hex mode shows no difference in the entire string view.

[ket]

Hi,

Could you please post a screenshot here showing the octal view of unsigned chars?
Usually characters are displayed in either decimal or hexadecimal mode (“Hex” button switches the mode) in addition to displaying the letter itself.

[ket]

Hi,

Thanks for writing your solution here.
Our suggestion would have also advised to stop blocking the SIGINT signal as that is used to break at breakpoints.

[ket]

Hi,

Based on your logs the ‘info shared’ responses look strange. That could be a reason why the symbols are not available or it could be normal for FlasCC.

Have you tried building and debugging the helloWorld example as described in the official FlasCC documentation at http://www.adobe.com/devnet-docs/flascc/docs/Reference.html#section_gdb ?
Try first gdb command line and then replicate the same in VisualGDB. Is it possible to set breakpoints into your code not only into FlashPlayerDebugger.exe in either case?

[ket]

Hi,

The deployment machine does not need the source code. The library symbol issues are probably also not related. Based on your log the following line makes VisualGDB think that the debugged program has exited:

reason="signal-received",signal-name="SIGINT",signal-meaning="Interrupt",reason="exited-signalled"

Try running the gdb from command line. While the program is running try Ctrl+C, does the gdb stop normally or the program exits?

[ket]

Hi,

What happens if you press on ‘Break all’ during execution?

[ket]

Hi,

It is somewhat unclear to us what exactly do you want to debug. Could you give us a concrete example?
If you want to debug system libraries (built with debug symbols, probably by yourself!) you should debug them through an app or a native executable. That should not require kernel debugging.

[ket]

Hi,

We can look into adding support for FlasCC. Definitely switching the machine interface mode off is not the answer as VisualGDB is a machine.
Could you please post a full GDB log (without mi modifications)? Are there any GDB startup commands that should be entered?

[ket]

Hi,

We looked more into this. It looks like an ANR (Activity Not Responding) issue, the logcat shows that the ActivityManager is killing the app due to it after 5 seconds on inactivity. On usual Android devices it is not an issue, as the device will just show a message asking whether to kill the app off. But on OUYA no message is shown, instead the app is killed off automatically.

To fix this, you need to select your app on OUYA as the debugged app. This setting is in Manage->Notifications->USB debugging connected->Debugging->Select debug app .

[ket]

Hi,

We have researched into this. Currently when a device is rooted, then we already start the gdbserver without the run-as command.
Based on the link you gave us there is a workaround to start the gdbserver without run-as from user mode on non-rooted devices?
We need more details on the workaround.
Based on the linked thread, the gdbserver is first started from within the Java app and then again from the adb shell. Starting the gdbserver again from the adb shell would however fail, as it would need root to start it directly.

[ket]

Hi,

Thanks for the information.
We can add such an option to 4.0.

[ket]

Hi,

Based on the log it is not the gdb that is killing the session. Are there any errors in the logcat? Furthermore, are you able to replicate the same with an hello world app? In other words does the same happen for all breakpoints and apps?

Btw, based on your log, you are using an older version of VisualGDB, try updating to version 3.1.r5 at least. If you have not updated NDK for a while as well, then update to the latest version r8e.

[ket]

Hi,

As long as in the VisualGDB Project Properties it is set that the remote X11 windows are shown on the Windows computer via XMing, the graphics forwarding should work.

Try the following:
1. Start debugging
2. Go to the SSH Console window and open a new shell.
3. Type into the shell: echo $DISPLAY

If the reply is 0, then the forwarding is not in effect. You could also try to install XMing again, when VisualGDB prompts it, the problems could be due to its installation.

[Author]

Posts