Summary: | Incorrectly displayed strings in variables/watch view | ||
---|---|---|---|
Product: | [Applications] kdevelop | Reporter: | nagytam |
Component: | CPP Debugger | Assignee: | KDevelop Developers <kdevelop-devel> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | jbb |
Priority: | NOR | ||
Version: | git master | ||
Target Milestone: | --- | ||
Platform: | Debian testing | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: | ||
Sentry Crash Report: |
Description
nagytam
2003-06-19 13:45:16 UTC
Is this within a c program or c++? and with char * strings, not QStrings or ... I'm assuming gdb 5.3? (but I suspect this isn't an issue here). Could you try using gdb at the command line and see what it says for those strings that are printed incorrectly as I'm relying on gdb (without any tricks) to print char * strings. The code is C and using char*... I compared the results of the variable view and the gdb view and it was not equally displayed... (I assume the variable view is buggy...) The gdb version is 5.3.20030606-2 (Debian), on i386. Note that, the last character of the strings was duplicated 3 times in all cases when this error occured... One more question :-) If you pop up the GDB tab in the output views what does the command and output look like for the strings printed incorrectly? jbb So here is an example of the error: The real string is "abc". Variables view: varname "abc..." where ... is a noisy random character GDB view: (gdb) print varname $42 = "abc\000...", where ... is exactly the same random string as in the Variables view I have 5 strings displayed, and the error occurs in only one case... Ah - I think I see what the problem is now varname is not a char* but a char[6]. If that is the case, then the error is that I'm stripping the \000 from the characters. You must be getting the same thing when running from the command line? Also try adding a watch variable of "(char*)varname". This should print "abc" (ie treated as a string.) jbb In SVN HEAD, for char p14[6] = "abc"; I get abc\000\000 in the variables widget, which is probably not nice but is exactly what gdb says. Can you check if the problem you report is there? No feedback, was working last time I've tried, closing. |