I am debugging a x86-64 device using Eclipse with gdb.
It was working fine till yesterday, when I cleaned my project and built it again. Now, I face a strange problem. It starts, and hits my first breakpoint. Then, I click Resume and it may run till my next breakpoint or give a remote failure reply e7295 error.
On the console I see these annoying lines:
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
My gdb commands are as follows:
set architecture i386:x64-32
set remotebaud 115200
target remote COM1
set disassembly-flavor intel
I restarted Eclipse and my laptop, I closed all unnecessary internal windows of Eclipse (memory browser, disassembly etc.), changed my serial cable, debugged the device with the same cable and project on my colleague's laptop.
What may be hindering gdb from debugging?
Related
I can start the Emulator and it starts the Android OS good and in 60 fps. However, shortly after the start of the Emulator, Android just freezes (not the Emulator) and is unusable.
I find this error code in the Event Log: Emulator: error deleting WGL context! error 0x6 and this in the idea.log:
Process hasn't generated any output for a long time.
If it's a long-running mostly idle daemon process, consider overriding OSProcessHandler#readerOptions with 'BaseOutputReader.Options.forMostlySilentProcess()' to reduce CPU usage.
Command line: C:\Users\ARES\AppData\Local\Android\Sdk\emulator\emulator.exe -netdelay none -netspeed full -no-snapstorage -avd Pixel_2_API_29
java.lang.Throwable: Process creation:
[...]
This started happening after I installed Android Studio on Windows 10 after reverting the OS from Ubuntu. On Ubuntu, everything ran fine.
EDIT: I found out that only the first start after Windows boot works properly. Any other starts in the same Windows session produce this error.
I've upgraded my Linux development VM from Ubuntu 16.04 to 18.04 recently, and noticed one thing that has changed. This is on x86-64. With 16.04, I've always had this workflow where I'd build the project I'm working on with gcc (5.4, the stock version in 16.04) and -fsanitize=address and -O0 -g, and then run the executable through gdb (7.11.1, also the version that came with Ubuntu). This worked fine, and at the end, LeakSanitizer would produce a leak report if it detected memory leaks.
In 18.04, this doesn't seem to work anymore; LeakSanitizer complains about running under ptrace:
==5820==LeakSanitizer has encountered a fatal error.
==5820==HINT: For debugging, try setting environment variable LSAN_OPTIONS=verbosity=1:log_threads=1
==5820==HINT: LeakSanitizer does not work under ptrace (strace, gdb, etc)
Then the program crashes:
Thread 1 "spyglass" received signal SIGABRT, Aborted.
__GI_raise (sig=sig#entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
I'm not sure what is causing the new behavior. On 18.04 I'm building with the default gcc shipped (7.3.0), using -fsanitize=address -O0 -g and debugging with the default gdb (8.1.0). Can the old behavior be somehow re-enabled? Or do I need to change my workflow and detach from the program before killing it to get a leak report?
LeakSanitizer internally uses ptrace, probably to suspend all threads such that it can scan for leaks without false positives (see issue 9). Only one application can use ptrace, so if you run your application under gdb or strace, then LeakSanitizer won't be able to attach via ptrace.
If you are not interested in leak debugging, disable it:
export ASAN_OPTIONS=detect_leaks=0
If you do want to enable leak debugging, you must detach the debugger before LeakSanitizer starts scanning. To be able to attach a debugger shortly afterwards, sleep a bit (for example, 10 seconds):
export ASAN_OPTIONS=sleep_before_dying=10
./program
Then in another shell, attach to the application again:
gdb -q -p $(pidof program)
For more a description of the above (and other) options, see https://github.com/google/sanitizers/wiki/AddressSanitizerFlags.
I have a Samsung Galaxy S8 and whenever I try to debug an app in Android Studio the app crashes and disconnects the phone from the PC.
I don't know if it's the drivers for the phone that I need to re-install or if there is a bug in the operating system or maybe something else.
I'm running Android Studio 3.1 under Linux Mint 18.3 Sylvia edition, and I'm running KDE.
Yes, there is a driver for Linux. You can get it from here:
https://dl.google.com/android/repository/platform-tools-latest-linux.zip
try following these steps to set it up correctly (I have it from https://www.xda-developers.com/install-adb-windows-macos-linux/)
Extract the ZIP to an easily-accessible location (like the Desktop for example).
Open a Terminal window.
Enter the following command: cd /path/to/extracted/folder/
This will change the directory to where you extracted the ADB files.
So for example:cd /Users/Doug/Desktop/platform-tools/
Connect your device to your Linux machine with your USB cable. Change the connection mode to “file transfer (MTP)” mode. This is not always necessary for every device, but it’s recommended so you don’t run into any issues.
Once the Terminal is in the same folder your ADB tools are in, you can execute the following command to launch the ADB daemon: adb devices
Back on your smartphone or tablet device, you’ll see a prompt asking you to allow USB debugging. Go ahead and grant it.install adb
Finally, re-enter the command from step #7. If everything was successful, you should now see your device’s serial number in the Terminal window output.
I try to build a reproducible automated build environment based on Debian 8.1 Jessie.
I created a boot iso image based on a netinstall image and put a preseed.cfg file in int for automatic installation.
I managed to get it bootable with BIOS and UEFI and can install a KDE Developer Debian in VMWare Workstation 11 fully automated.
I have also a server iso image to install a debian Server with Jenkins, both with BIOS and UEFI Boot.
But after the installation, the Version with UEFI Boot shows a black Screen when started.
I can blindly log in, start the gui with "startx" and see my installed xfce desktop. When i quit xfce the console is usable and visible.
I tried suggested bootparameters "nomodeset" and "vga=Linux" that i found with google to no avail.
I also tried to debug the boot prozess, to find out which command leads to a blank screen, but i did not find the right place to delay the processes at bootup so i can see when the messages dissapear (quiet bootparameter was removed :-)
I also tried to reset the console to no avail.
Can anybode point me to a tool that does the same "switching" like X so the console is useable?
Can anybody give me some hints how to debug the bootprocess to find out which command is causing this behaviour?
I dont want to install X because this should be a headless server system later.
I managed to get my system to boot using the kernel command line modprobe.blacklist=vmwgfx, or placing 'blacklist vmwgfx' in /etc/modprobe.d/*.conf
I assume it is some bug in the vmwgfx module, however as this workaround works for me I have no immediate need to investigate further.
I am running Xubuntu on a 64 bit machine. When trying to debug a Beaglebone using gdb (via Eclipse) I get the following error message:
"Remote 'g' packet reply is too long"
See here for more details:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=509479
At the host I am using gdb-multiarch.
When start it, it announces:
"This GDB was configured as "x86_64-linux-gnu"."
Can you please tell me how to configure GDB to work with a 32 bit target? Any other thoughts?
Thank you.
As far as I know the BeagleBone uses an ARM processor.
You'll have to get the ARM version (more precise: version for debugging ARM processors) of GDB to debug - you cannot do this with the x86 version.
For Windows the ARM version is available in the "WinARM" packet.
Maybe for Linux such a packet does not exist and you'll have to re-compile GDB.
Add "set architecture arm" to the .gdbinit file referenced in Eclipse under Debug Configurations -- Debugger -- GDB command file. Make sure the .gdbinit file can be found at run-time by making sure GDB command file contains full path to file.
I encountered a similar issue trying to set up cross compilation through Eclipse with a Ubuntu 12.04 Host VM running on a Mac connecting to a Beaglebone Black target. When trying to debug my project, I would get the same "Remote 'g' packet reply is too long" error. What solved this issue for me was to go into the Debug Configuration for your project, select the Debugger tab, and replace gdb to gdb-multiarch the GDB debugger field.