View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000047Ecere SDKidepublic2008-04-30 20:162012-03-29 07:52
Assigned Tojerome 
PriorityimmediateSeveritymajorReproducibilityhave not tried
PlatformOSOS Version
Product Version 
Target VersionFixed in Version 
Summary0000047: GDB dialogue protocol errors, new gcc tool versions
DescriptionFind 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.
TagsNo tags attached.
Attached Files

- Relationships
child of 0000433closed previously resolved issues (draft 1 of 0.44 and earlier) 

-  Notes
redj (administrator)
2008-05-03 08:33

============ trying mingw 4.3.0 ============
   Sources\sys\ warning: incompatible expression &windowHandle (struct HWND__ * *); expected int
   Sources\sys\ warning: incompatible expression &windowHandle (struct HWND__ * *); expected int
   Sources\sys\ 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\ error: lvalue required as left operand of assignment
   Sources\sys\ error: lvalue required as left operand of assignment

ecere.dll (Debug) - 3 errors, 3 warnings
redj (administrator)
2008-05-19 02:51

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?
redj (administrator)
2008-05-19 02:51

:P see earlier note
jerome (administrator)
2008-06-12 14:33
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
- F5
- F10 : whole app / IDE jams...

For overflowing problems, the most common scenario is on a stack overflow. (Just make a function recursively call itself).

jerome (administrator)
2008-08-26 03:24
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 .

- Issue History
Date Modified Username Field Change
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
Powered by Mantis Bugtracker