|Anonymous | Login | Signup for a new account||2020-07-14 14:00 UTC|
|My View | View Issues | Change Log | Roadmap|
|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000047||Ecere SDK||ide||public||2008-04-30 20:16||2012-03-29 07:52|
|Priority||immediate||Severity||major||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0000047: GDB dialogue protocol errors, new gcc tool versions|
|Description||Find out the cause and prevent protocol errors from happening.|
They often happen e.g. due to long call stacks overflowing buffers.
Also test the debugger and make it work with latest GDB version.
Test with MinGW/ GCC 4.
|Tags||No tags attached.|
============ trying mingw 4.3.0 ============
Sources\sys\File.ec:772:67: warning: incompatible expression &windowHandle (struct HWND__ * *); expected int
Sources\sys\File.ec:775:42: warning: incompatible expression &windowHandle (struct HWND__ * *); expected int
Sources\sys\File.ec:827:61: warning: incompatible expression &nr (struct _NETRESOURCEW *); expected struct _NETRESOURCEA *
Objects\Ecere\Win32\Debug\File.c:3461: error: two or more data types in declaration specifiers
Sources\sys\File.ec:1382: error: lvalue required as left operand of assignment
Sources\sys\File.ec:1684: error: lvalue required as left operand of assignment
ecere.dll (Debug) - 3 errors, 3 warnings
currently running gcc 4.3.0 and gdb 6.8
I don't much complaining of gdb protocol errors, do you?
any test case?
and what is this last note?
|:P see earlier note|
edited on: 2008-06-12 14:35
Some occasional problems seem to be caused by overflowing problems, however major problems seem to be Linux specific. Something as simple as:
- Set a breakpoint
- F10 : whole app / IDE jams...
For overflowing problems, the most common scenario is on a stack overflow. (Just make a function recursively call itself).
edited on: 2008-08-26 03:30
The overflowing in Linux were made worst by the facts that the Linux default call stack size is much bigger.
GDB needs to walk through all the frames to get to the highest frames (even for a simple frame count with -stack-info-depth) and ate up a lot of memory and CPU doing so. The maximum backtrace size has been limited to 100000 to prevent the machine from being taken over by GDB.
The F10 jams was most likely related to issue 0000124 and the ^error "Cannot find bounds of current function". The biggest communication problem was related to issue 0000007 whereas the GDB dialogue as intertwined with the program output.
The overall GDB communication has also been much improved by replacing GetLine with a block reading code (blocking) which uses a dynamically expandable string buffer (set a 4k minimum size) to gather together single lines. The DualPipe::Read on Unix has been modified to use read instead of fread so that it doesn't wait for the entire block to be read (DualPipe::Eof required modifications as well).
Another important improvement was the modification of the gdbTimer.DelayExpired function to keep the stopItem at its entry (and setting the Debugger one to null) in the same manner it was saving "event" to its local curEvent variable. This prevents changes to stopItem which were happening as it executed the GdbCommand calls.
This issue was originally reported to figure out the problems on Linux, then thought that it could be first tested with GCC 4 on Windows (which worked just as well as the 3.x on MinGW). These few issues were mainly responsible for it, and it seems we can finally enjoy a functional debugging environment on Linux :D .
|2008-04-30 20:16||jerome||New Issue|
|2008-04-30 20:16||jerome||Status||new => assigned|
|2008-04-30 20:16||jerome||Assigned To||=> redj|
|2008-05-02 01:09||jerome||Priority||normal => high|
|2008-05-03 08:33||redj||Note Added: 0000020|
|2008-05-12 17:30||jerome||Priority||high => urgent|
|2008-05-19 02:51||redj||Note Added: 0000050|
|2008-05-19 02:51||redj||Note Added: 0000051|
|2008-05-19 02:51||redj||Status||assigned => feedback|
|2008-06-12 14:33||jerome||Note Added: 0000053|
|2008-06-12 14:33||jerome||Status||feedback => assigned|
|2008-06-12 14:35||jerome||Note Edited: 0000053|
|2008-08-15 16:03||jerome||Priority||urgent => high|
|2008-08-17 18:19||jerome||Priority||high => immediate|
|2008-08-17 18:19||jerome||Severity||minor => major|
|2008-08-22 01:09||jerome||Assigned To||redj => jerome|
|2008-08-26 03:24||jerome||Note Added: 0000088|
|2008-08-26 03:25||jerome||Note Edited: 0000088|
|2008-08-26 03:27||jerome||Note Edited: 0000088|
|2008-08-26 03:27||jerome||Status||assigned => resolved|
|2008-08-26 03:27||jerome||Resolution||open => fixed|
|2008-08-26 03:30||jerome||Note Edited: 0000088|
|2009-05-03 03:43||jerome||Status||resolved => closed|
|2010-07-25 21:33||redj||Relationship added||child of 0000433|
|2012-03-29 07:52||redj||Category||=> ide|
|2012-03-29 07:52||redj||Project||@3@ => Ecere SDK|
|Copyright © 2000 - 2020 MantisBT Team|