I'm trying to debug a relatively simple OS using QEMU and GDB.
The problem is that the bootloader loads the OS executable and then randomly relocates the OS code and data pages to different parts of memory. This is to implement the Address Space Layout Randomisation (ASLR) security feature.
The OS executable has been built with debug symbols, so in theory, I just need to tell the GDB debugger where these symbols are in memory. However, because they have been randomly relocated, I have no idea where they are.
Are there any GDB commands or scripts I can use to find the different parts of the executable in memory? Maybe based on code fingerprinting?
However, because they have been randomly relocated, I have no idea where they are.
There are two usual approaches to this:
disable ASLR to ease debugging
have the loader print the relocated address (which you can then use to tell GDB where the relocated object resides).
Are there any GDB commands or scripts I can use to find the different parts of the executable in memory?
Yes, you can use the GDB find command if you there is a known byte sequence you are looking for.
Related
I've written a shared library in C/C++ for MATLAB to create an API for a Monochrome camera.
The code works, but I have some odd issues with memory management (basically the MATLAB functions for freeing/dynamically allocating aren't too reliable). Additionally I have some other really low level things I'd like to debug like looking at values of register holding raw camera buffer.
I can write standalone C Code and launch it with GDB, however a child process will crash the software as only 1 thread is allowed to open a connection to camera at a time. If I don't set break points within the code interacting with device all is fine. But I want to stop the program say after acquiring image buffer, but before copying the data into MATLAB output, the child process spawned by the debugger causes everything to lock up.
Anyone know how I might address this?
Edit: "Unreliable" is not a good wording. Basically, I retrieve an image buffer from camera (which is dynamically allocated because image bitdepth is variable). This array is created/destroyed with mxMalloc and mxDestroyArray which works okay if I have MATLAB_MEM_MGR enabled. This is part of what I would like to debug inside MEX. The other is comparing the raw byte values of the image buffer before coming back to matlab.
Additional Clarification:
The error I get in GDB is actually a GenICam error for RESOURCE_IN_USE. My intuition is because the parent process hasn't released the camera resources, the child thread started actually causes issues if that makes sense.
On Windows, it seems somewhat dangerous to switch from VC++ to MinGW-w64 for a MEX, as you can easily wind up with the classic Windows bug of having multiple copies of libc. See the warning here, "Do not link to library files compiled with non-MinGW compilers". A MEX built with 'gcc' will pull in malloc() and free() from msvcrt.dll, whereas any DLLs you link against that were built with 'cl' will pull in ucrtbase.dll instead. That could easily lead to crashes, if for instance gcc-compiled code calls free() on a block allocated using malloc() in cl-compiled code.
The gdb.exe installed by MATLAB does seem to behave somewhat strangely, especially when I press Control-C. It doesn't like Cygwin terminals either. It does spawn a weird 'gdborig' helper process. Finally, I kept seeing a Microsoft A/V tool, mpcmdrun, firing off as I was playing with it. You might try the newer gdb installed by MSYS2 (although I may have seen A/V there as well).
Indeed, some random child process probably inherited the device connection handle, causing the lock-up. But that child process might be something else... not be the extra one created by that silly old version of gdb (7.11.1).
An executable is loaded and run in WinDbg
It loads modules it needs at certain addresses
Breakpoints set/traces retrieved in this session depend on these addresses
When another session is started for the same executable, (either depending the on the code execution path changing dll dependency order, or some indeterministic loader behavior?) the modules are now loaded into different addresses.
It would have been helpful if there was a way to instruct windbg/loader to load the not-yet-loaded modules at given addresses. This would make certain scripts/text-comparisons much easier.
Yes, I do realize that for example, setting breakpoints relative to symbol names should be preferred instead of using fixed addreses, but being able to "reproduce" a reference debugging environment definitely has certain advantages.
Assuming we're dealing with 3rd party DLLs (that I cannot recompile with predefined loading addresses), is there a way to do this?
I was so happy to see .reload command has an address parameter, which looked like it would do exactly what I'm asking. However, even though that command would load the modules, when the program is continued (and the actual dll load is needed), it would go ahead and still load another copy(?) for the same module, and give a warning like:
WARNING: moduleX_1be0000 overlaps moduleX
So it didn't really work like I expected, thus this question!
WinDbg does not load modules (DLLs). The modules are loaded by the executable.
The ld and .reload commands of WinDbg do not load modules, they load symbol information (PDB files).
The process of changing the address of a module is called rebasing. It happens if the base address is not available any more, e.g. in use by a heap already. In that case, you cannot prevent rebasing at all.
One thing that might help is disabling ASLR (address space layout randomization). You can change that setting in a DLL or EXE. It's part of the COFF header:
On Windows 7, there were ways to disable ASLR completely, but it's not recommended to change that setting on a per-system basis just to help you debug a single process.
Another option would be to use rebase.exe of the Windows SDK and change the base address to a virtual address that you think is more likely to be free at the time the DLL is loaded. I never did that myself, but the rebase help says:
If you want to rebase to a fixed address (ala QFE)
use the ##files.txt format where files.txt contains
address/size combos in addition to the filename
so, it sounds possible to define your own address.
I'm tasked with upgrading a lot of legacy models and scripts made in an older version of Matlab/Simulink and have it running smoothly in R2018b. Among other requirements I'm not allowed to have any warnings issued upon execution of .m scripts or Simulink models. This is generally tedious but straightforward to comply.
However, there is a specific warning that Matlab does not give me hints on possible sources:
Warning: MATLAB has disabled some advanced graphics rendering features by switching to software OpenGL. For more information click here.
The link opens the Matlab Help page titled Resolving Low-Level Graphics Issues, which describes issues I'm not finding (or at least not noticing)
I do note that many scripts I run create and close figures, but this is done procedurally. I haven't been able to associate this warning with some specific function or feature. I'm working on a Windows Server machine.
Does anyone have an idea of how to narrow down which kind of function os Simulink block could cause this warning?
As datenwolf and Ander point out, the first thing to try is to update your drivers. If this doesn't work, and your only problem is that you're getting the warning but your graphics still render fine, then you have two other options to try.
First, you can simply modify your OpenGL rendering preferences using opengl. The following will set your preference to 'software' and save that setting for future sessions:
opengl('save', 'software');
Alternatively, you can just try to suppress that particular warning message. After you get the warning, issue this call to the warning function:
w = warning('query', 'last');
The w.identifier field will give you the ID for the warning message, which I believe will be 'MATLAB:hg:AutoSoftwareOpenGL' in this case. You can then add the following line to your startup.m file so that this warning is suppressed every time MATLAB is opened:
warning('off', 'MATLAB:hg:AutoSoftwareOpenGL');
Install the original vendor drivers for your GPU. The drivers that are installed by Windows by default lack full OpenGL support. Download the driver package directly from the website of Intel, AMD or NVidia, depending on what GPU you have.
If you don't have GPU, for example when running in a Virtual Machine, then you can not avoid that warning, because then Matlab has no other choice than falling back on the software OpenGL implementation that it ships with.
There's nothing you can do about that, other than making sure, that the system you're running Matlab on, does have proper OpenGL support!
It took me a long time to get it, so I'll put you here in case it helps how I managed to activate openGL in Linux:
If you haven't already (it's common for other problems), rename libstdc++ library from MATLAB:
mv _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6 _YOUR_MATLAB_ROOT_FOLDER_/sys/os/glnxa64/libstdc++.so.6.bak
Create this link: sudo ln -s /usr/lib/x86_64-linux-gnu/dri/ /usr/lib/
Run export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER;matlab -desktop -nosoftwareopeng
Your DRI Driver will be a file from /usr/lib/dri, removing "_dri" (in my case was the "radeons" driver for an AMD Vega graphic card.
Run MATLAB from a terminal using: export MESA_LOADER_DRIVER_OVERRIDE=_YOUR_DRIVER_HERE_;matlab -desktop -nosoftwareopengl. YOUR_DRIVER_HERE should be your driver, radeonsi in my case.
Check openGL with info = rendererinfo
If something went wrong, you will be able to see in the terminal which library was responsible. Executing 4) and 5) I was discovering what I had to correct, you can do the same if you have another problem that has not appeared to me.
So that it always runs correctly I put export MESA_LOADER_DRIVER_OVERRIDE=YOUR_DRI_DRIVER at the beginning of the script that runs matlab (_YOUR_MATLAB_FOLDER/bin/matlab), although I suppose it can also be set as an environment variable.
I hope this has been useful to you.
My client has an old version of uClinux, kernel 2.6.22, running on a Blackfin STAMP board. The main application is divided into 14 processes, plus there's a webserver running on the board.
The bug we're seeing, the webserver keeps running happily along while the VOIP application seems to run out of file handles and can't create new sockets. I've tried every debugging technique I know of. I have a JTAG debugger but the memory is too small for debug symbols. I can't compile with Valgrind or anything like that. Any guesses?
Thanks,
Mike
It's likely you've got a file descriptor leak. Valgrind isn't the best tool for tracking that down anyway.
Start by doing 'ls -lah /proc/pid/fd'. That'll show you a list of file descriptors opened (and not yet closed) by the process.
If you've really got a file descriptor leak you should see a lot of entries there. It should also be immediately obvious which type of file descriptor you're leaking (file, socket, ...).
Once you know that you'll have a better idea of where in the code to look for the leak.
The fact that your file system is full may be another hint. If your application is creating a file and removing it, but not closing the file descriptor, you might have a bunch of files which you won't find in the tree but which still eat up space hanging around. In that case you'll see the file names in (the target of the symlinks in) /proc/pid/fd.
I have a perl script, if i run it normally, it doesn't work right.
But if i run it with the debugger and set a breakpoint at a very specific line, then the script operates correctly.
What side effects can the, breakpoints of the ptkdb module, have?
Loading of any perl debugger has quite significant impact on all environment -- for an idea look into perldebguts. While the debuggers try hardly to minimize its effects, there are additional packages loaded, some special variable has different contents, timing of runtime changes, etc. Without more detail it is hard to say what difference is affecting you.
I would recommend to debug using logger (I found easy mode of Log::Log4perl very handy for this). Also many useful hints on debugging art is in perldebtut.