Version: 3.4.1 (using KDE 3.5.7, Gentoo) Compiler: Target: i686-pc-linux-gnu OS: Linux (i686) release 2.6.22-gentoo-r2 I'm sorry if I accidentally duplicated the bug report 104962, but I think that this bug is a bit different. So, I have a custom implementation of string class, that contain 'int m_len' and 'char* m_buf' fields. When I debugging a program I've noticed that actual value of the 'm_buf' field does not always correspont to that shown in 'Locals' in Variable List. But 'm_len' do! Another thing: If I put a watch on m_buf and step through the program it will display the value correctly (it will change to red and update it's value, whether tree item in Locals don't). Please notice, that if I use string as local variable (not as a field) the bug dissapears. So in code like this.. string s; s = "hello world" ..both m_len and m_buf are updated. P. S.: Thanks a lot guys! You're making a great soft! :) Hope that my report will help to fix the bug. P. P. S.: Sorry for my english ;)
Can you reproduce this with other data structures in your programs? Does this happen with plain char* for example? Can you post some example code where this can be easily reproduced?
Created attachment 21488 [details] error reproducing source code and a couple of screenshots
Comment on attachment 21488 [details] error reproducing source code and a couple of screenshots This is an archive containing 3 files. one source file and two screenshots. To reproduce the bug, simply create new plain C++ "hello world" project, and replace the main .cpp with the file provided. Then compile the source, put the breakpoint to the line 66 and run the program under debugger. You need to expand the variable tree so the m_len and m_buf will be visible. You may also add a watch "ms.s.m_buf". Now, step through the source and see how the values are changed. Screenshot 1 captures the exact moment when the new value is assigned to the field, but the tree node 'm_buf' does not updated (stil shows ""). Note that gdb provides correct information (see the gdb console and the result of the 'print' command) Screenshot 2 shows that subnode of m_buf is actually correct.
Oops. Seems that i missed the content type. Actually that is .tar.bz2 achive. (the code inside is a subset of my string class)
Comment on attachment 21488 [details] error reproducing source code and a couple of screenshots fixed the MIME type. sorry for flooding
Hmm interesting. Using this little change to your app I could "fix" the problem in kdevelop: --- report_old/bug149240.cpp 2007-08-27 12:05:07.000000000 +0200 +++ report/bug149240.cpp 2007-08-29 00:11:27.000000000 +0200 @@ -22,7 +22,7 @@ { if(m_buf) free(m_buf); - m_size = (len+17) & ~0xF; + m_size = (len+1)*sizeof(char); m_buf = (char*)malloc(m_size); m_len = len; memcpy(m_buf, s, m_len); @@ -33,7 +33,7 @@ string(dword size = 0) { - m_size = (size + 16) & ~0xF; + m_size = size*sizeof(char); m_len = 0; m_buf = (char*)malloc(m_size); m_buf[0] = 0; And the full GDB output gives a hint that GDB doesn't report a change for m_size and m_buf variables when stepping over the assignment in line 67. So this looks like a gdb-mi bug (I'm using gdb 6.6 here) not a kdevelop problem. This can also be seen in the variables view, only the watch (which is always evaluated) and the m_len member are highlighted "red" indicating they have changed.
I'm not yet closing this maybe I can ping Vladimir so he can have a short look.
This is gdb behaviour. For value of "char *" type, gdb 6.6 does not report when the string changes, only when the pointer value itself. This behavior was changed in gdb CVS, and when I've tried with gdb CVS, the m_buf was updated. You can either build gdb from CVS yourself, for wait for gdb 6.7 release, that should be out within a month.
re-open to close as invalid.
"FIXED" is not the right solution as this is not a bug in kdevelop that could be fixed. The bugreport is invalid as the problem is not within kdevelop.
Ok, will be waiting for the next version. Thanks a lot.