User forums > Help

Strange behaviour in memory window while debugging

(1/2) > >>

gygabyte017:
Hi, I'm trying to debug a simple C program with Code::Blocks. In memory window, while debugging (I see correctly the disasm window with yellow arrow at the line debugged), if I write an incorrect address (e.g. 0x0) in output I see "Cannot access memory at address 0x0", but if I put a correct address (e.g. &i), the output is blank. Not really blank, it's filled by X blank spaces (the X is the number of bytes set in combobox).
So it seems that there is a problem in showing memory dump. Is there a bug? Or I'm doing something wrong?

I post an image to show what happens: [img=http://img516.imageshack.us/img516/2005/schermataep9.th.png]

Thanks

gygabyte017:
I've noticed that in windows version of Code::Blocks, this error does not happen... So it seems to be a unix problem?!
Is there any ubuntu user that has some data in memory dump window ??

Thanks again

Jenna:
After your first post I tested it on debian and had the same problem.

Today I wanted to debug C::B to look for a possible bug and ...
... it works as expected.

I'm a little bit confused, because I did not update any relevant files since yesterday afaik.

debian sid/experimental, 64 bit, C::B svn r5074
gdb 6.8-3, gcc 4.2.3-6, g++ 4.2.3-9, libstdc++6 4.3.0-4, libc6 2.7-11

Jenna:
It's definitely a bug in C::B's debugger plugin, due to incorrect/insecure use of wxString::Format with format-string "%s" and a wxChar-Array.

--- Quote ---On (some) linux systems the memory dump randomly shows nothing but blanks.
The problem is using of wxString::Format with format-string "%s" to show the wxChar[] m_LineText in ExamineMemoryDlg::AddHexByte.

The Format-function for char-arrays needs either a null-terminated string or an explicitely given precision to know the end of the string.

In some cases the last byte after m_LineText is not 0 and the function tries to read more what leads to the following error-message in the console (if C::B is started from commandline):
"(codeblocks:890): Gtk-CRITICAL **: gtk_text_buffer_emit_insert: assertion `g_utf8_validate (text, len, NULL)' failed".

--- End quote ---

It was not so easy to track it down, because it only happens randomly.

I described the bug here and posted a patch.

There seems to be no other place where Format is used in this way. In all other places a ".c_str" is used and that returns a null-terminated string I guess.

Jenna:
@gygabyte017

Can you test the patch yourself ?

I will upload patched debian packages to my repository during this day.

EDIT:

It's in my repo now.

Navigation

[0] Message Index

[#] Next page