Developer forums (C::B DEVELOPMENT STRICTLY!) > Development

Patch for codeblocks 20.03 adding multi columns in memory dump

<< < (5/9) > >>

MicroSourceCode:

--- Quote from: ollydbg on February 18, 2021, 04:13:29 pm ---Something maybe off topic, but I'm interested in view the memory as an image.
I'm mainly developing image processing algorithm, such as OpenCV's cv::Mat.

--- End quote ---

Is it a memory pointer? If a pointer is present then the pretty printer can handle this memory. TCP connection will be significantly slower, do you want to process the data stream through wxwidget to display it?

ollydbg:

--- Quote from: MicroSourceCode on February 21, 2021, 10:28:09 am ---
--- Quote from: ollydbg on February 18, 2021, 04:13:29 pm ---Something maybe off topic, but I'm interested in view the memory as an image.
I'm mainly developing image processing algorithm, such as OpenCV's cv::Mat.

--- End quote ---

Is it a memory pointer? If a pointer is present then the pretty printer can handle this memory. TCP connection will be significantly slower, do you want to process the data stream through wxwidget to display it?

--- End quote ---

No, it is not a memory pointer, it is just a normal variable. Let me explain below:

There are mainly 3 parts, each part has a seperate process.

The first part is the debugee, where the cv::Mat resides. It is just a normal variable which has the type cv::Mat.
The second part is the GDB, where I can run the Python pretty printer to fetch the debugee's memory, the memory is usually huge, for example, a 1000*1000 pixel image, one byte for each pixel, then it is 1M bytes.
The third part is the Code::Blocks or the debugger plugin, which communicates with GDB by pipes(stderr, stdout, stdin).

I would like the show the image in the debugger plugin, so I need to find a way to pass the huge memory(1M bytes in my example) from the GDB to Code::Blocks. I'm not sure it is OK to through the command pipes, I think this will pollute the norman command line based communication. So, I would find a way such as using TCP.

BTW: the reason I would like to show the image in Code::Blocks' process is that I can show the image in GDB's process(by using the Python's GUI), if GDB is running, those GUI will hang.

MicroSourceCode:
Quite intricate. Don't want to use BlueHazzard's memory interface? Take the memory you want, then do something like this:

Mat image (1920, 1080, CV_8UC3);
typedef cv :: Point3_ <uint8_t> Pixel;
// first. raw pointer access.
for (int r = 0; r <image.rows; ++ r) {
    Pixel * ptr = image.ptr <Pixel> (r, 0);
    const Pixel * ptr_end = ptr + image.cols;
    for (; ptr! = ptr_end; ++ ptr) {
        ptr->x = 255;
    }

and convert cv::Mat to wxBitmap for output to window. This is simplified, the data can be compressed.

https://github.com/PBfordev/wxopencvtest

ollydbg:

--- Quote from: MicroSourceCode on February 22, 2021, 12:46:56 pm ---Quite intricate. Don't want to use BlueHazzard's memory interface? Take the memory you want, then do something like this:

--- End quote ---

If I understand correctly, BlueHazzard's memory interface just use the GDB's memory dump command Memory (Debugging with GDB).

Normally, a cv::Mat has a header part and follows the GRAY/RGB raster color byte array. I can find the start address of the raster byte array, and construct a wxBitmap.

The only concern is that I'm not sure if dump a huge memory(for example, a 5M byte memory) is possible. Will it cause slow down of GDB pipes?

oBFusCATed:
It will be slow, because of the slow communication (mostly on the C::B site) between C::B and gdb.
But the biggest problem is that you don't have an easy way to show an image in C::B from the debugger.
You could probably do this in gdb-python-only by making a command which stores an image on disc every time you execute it. After that you could use your favourite image viewer to inspect it.

Navigation

[0] Message Index

[#] Next page

[*] Previous page

Go to full version