Strange behaviour in memory window while debugging

[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.

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".

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.

[gygabyte017]

@jens

ok, now it works, thanks!

But there are still problems with addresses shown at the left of dump window... Randomly, all rows have address '0x7fffffff' instead of the address written on textbox... Sometimes addresses are correct, sometimes they aren't..

[Biplab]

But there are still problems with addresses shown at the left of dump window... Randomly, all rows have address '0x7fffffff' instead of the address written on textbox... Sometimes addresses are correct, sometimes they aren't..

Fixed in revision 5077.

[gygabyte017]

Perfect! Thanks!