Author Topic: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.  (Read 35430 times)

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Get quick announcements through the RSS feed http://www.codeblocks.org/nightly/CodeBlock_RSS.xml

Before you use a nightly make sure you understand how it works.

A link to the unicode windows wxWidget dll for Code::Blocks : http://prdownload.berlios.de/codeblocks/wxmsw28u_gcc_cb_wx2810_gcc441.7z

For those who might need this one (when no MingW installed on your system) : the mingw10m.dll : http://prdownload.berlios.de/codeblocks/mingwm10_gcc441.7z

The 27 November 2010 build is out.
  - Windows :
   http://prdownload.berlios.de/codeblocks/CB_20101127_rev6863_DEBUGGER_BRANCH_win32.7z
  - Linux :
   none

Important changes compared to previous DEBUGGER BRANCH nightly:
* debugger_branch: applied patch by cbexaminr and oBFusCATed with the following features:
- check UpdateDisassembly() rather than UpdateBacktrace() for CMD_STEP_INTO_INSTR handling
- call NotifyCursorChanged() on CMD_STEP_INTO_INSTR and CMD_STEP_INSTR to update any of various affected windows that may be open
- modify disassembly display functionality in effort to:
-- reduce number of times (re-)disassembly requested from gdb
-- when possible avoid total redraw of disassembly and simply reposition "current" instruction gutter indicator
-- correct (one) possible disassembly display failure when program position moved to lower memory address
- modify some of stack frame change response handling to avoid disassembly of area on autoswitch since may not reflect current program instruction
- support "Mixed Mode" disassembly display
- add functionality to let user quickly switch "current" instruction position between top/middle/bottom of disassembly window
- correct cut-n-paste comment error on GdbCmd_InfoRegisters
- NOTES - (with regard to mingw-built GDB 7.2):
-- response information returned from GDB is sometimes missing current instruction address which results in some (re-)disassembly that might otherwise be avoided. (I have not found an architecture independent means of determining the current instruction address to work-around these omissions. GDB's "$pc" changes according to the currently selected stack frame, which may be changed by autoswitch functionality, so cannot be used.)
-- response information returned from GDB for a mixed mode disassembly sometimes fails to include instructions that are present in the target. Hence they cannot be found and indicated in the disassembly display.
* debugger_branch: applied dbg_refactor0017.7.patch:
- added GetIsRunning method to ProjectManager, it is used to query the plugin that is running the project (running the application, debugging the application, etc)
- added SetIsRunning method to ProjectManager, it is used to set the plugin that is running/executing the project, it is set only if the GetIsRunning returns NULL
- modified the Compiler plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
- modified the Debugger plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
- fixed all (almost), bugs encountered since v17.3
* all updates that occurred on trunk


Note: Watch parsing prints an error message in the watches window if the parsing fails. If you see this string please report it as a bug.

THIS IS A SPECIAL TEST BUILD OF REFACTORINGS CARRIED OUT ON THE DEBUGGER BRANCH IN OUR SVN.
FOCUS IS ON ENHANCED DEBUGGING USABILITY.

Give your feedback on this version only in this thread, don't mix it with the regular nightly please.

Once we don't have any blockers on this version,we will merge the changes into trunk and it will be part of the regular nightlies.

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #1 on: November 27, 2010, 03:31:33 pm »
Debian packages (binaries and sources) for 32-bit and 64-bit systems can be found in my repo.

If you want to use apt (or dselect, synaptic or whatever) you need to add the following entries to /etc/apt/sources.list :
Code
deb http://apt.jenslody.de/ any dbg
deb-src http://apt.jenslody.de/ any dbg
and remove entries for the normal nightlies.

Alternatively you can download the deb's directly from http://apt.jenslody.de/pool/dbg/c/codeblocks/ .

mariocup

  • Guest
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #2 on: November 27, 2010, 05:09:05 pm »
Hi,

I tried "Mixed Mode" disassembly display but getting waiting while disassembling and nothing happens. I am using gdb 6.8. Do I need a newer version?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #3 on: November 27, 2010, 06:09:07 pm »
mariocup: can you paste the debugger's debug log?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #4 on: November 27, 2010, 06:29:15 pm »
Hi,

I tried "Mixed Mode" disassembly display but getting waiting while disassembling and nothing happens. I am using gdb 6.8. Do I need a newer version?

same thing, on a simple hello world program-ish program ;-)

Offline mushakk

  • Multiple posting newcomer
  • *
  • Posts: 54
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #5 on: November 29, 2010, 10:49:05 am »
Thanks and good job!

 :D

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #6 on: November 29, 2010, 12:49:31 pm »
killerbot: can you paste the debugger's debug log?  :lol: 8)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #7 on: November 30, 2010, 11:43:27 am »
voila, on my linux box I switched to the debugger branch :-)

Some first requests/issues.

In a program I want to be able to use CTRL-Z. However the debugger (gdb) is going to catch this, so where I normally would issue the following command in gdb :

Code
handle SIGTSTP nostop noprint pass

I know added this to the Debugger settings -> Debugger intialization commands [note the typo in CB : intialization] :
Code
handle SIGTSTP nostop noprint pass

When the debugger session from within CB has started, I check the Debugger->Information->Signal handling, and we see a nice entry : no no yes.
So this is good, however inside the program, cntrl-Z does NOT do what it supposed to do.
This does however work when the program was launched through gdb on the command line (and issueing the handle command in gdb).

Any idea why this doesn't work when the launch happened from CB ?

Request : currently we show the signal table purely informational, wouldn't it be nice that this table could be modified, so we can hide the handle command alltogether, and maybe CB could store this information so it doesn't have to be entered each time ?

What do you guys think ?
« Last Edit: November 30, 2010, 11:45:20 am by killerbot »

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #8 on: November 30, 2010, 11:50:05 am »
Another request :

During a debugging session, one ends up at a given statement in a certain file.
Then one browse around :
- opening other files to look up something
- selecting another frame from the call stack
- ...

Result : you get lost ;-) and have no clue where your last executed statement was, and you want to return to that statement, so you can "see your" "next line" action.

Currently this can be done by going to the callstack and click on the deepest level.

It would be nice, if there was a dedicated button for that in the toolbar, I have seen it in other IDE's (typically the yellow arrow), which just brings the editor of the file containing the "next to execute" statement.

What do you think ?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #9 on: November 30, 2010, 12:32:52 pm »
In a program I want to be able to use CTRL-Z. However the debugger (gdb) is going to catch this, so where I normally would issue the following command in gdb :
....
When the debugger session from within CB has started, I check the Debugger->Information->Signal handling, and we see a nice entry : no no yes.
So this is good, however inside the program, cntrl-Z does NOT do what it supposed to do.
This does however work when the program was launched through gdb on the command line (and issueing the handle command in gdb).

Any idea why this doesn't work when the launch happened from CB ?
Have you tried this:
1. start gdb
2. start terminal
3. attach the output of the inferior/debuggee to the terminal using the tty command
4. same as before

My guess is that ctrl+Z is handled inside gdb, not in the debuggee, so if you execute ctrl+z in the terminal there is no way for gdb to receive the signal.


It would be nice, if there was a dedicated button for that in the toolbar, I have seen it in other IDE's (typically the yellow arrow), which just brings the editor of the file containing the "next to execute" statement.
What do you think ?
It is easy to do, but I'm not sure if it is good to waste more space in the toolbar...
Most of the time the Callstack window is too usefull to be closed/hidden:)

But I've added it to my todo, some day I could implement it...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #10 on: November 30, 2010, 01:04:35 pm »
or we can start with an entry in the Debug menu, and right click context menu, right ?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #11 on: November 30, 2010, 01:16:59 pm »
or we can start with an entry in the Debug menu, and right click context menu, right ?
Yes for Debug menu
No for the context menu, it is too crowded already
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5490
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #12 on: November 30, 2010, 01:20:29 pm »
what about grouping all the debug related ones in a submenu Debug in the right click context menu (toggle breakpoint , run to cursor,  set next statement) ?

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #13 on: November 30, 2010, 02:33:45 pm »
Could we hide the remote console on MSW with something like the following:

Code
Index: src/plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- src/plugins/debuggergdb/debuggergdb.cpp (revision 6710)
+++ src/plugins/debuggergdb/debuggergdb.cpp (working copy)
@@ -831,6 +831,13 @@
         SetConsoleTitleA("Codeblocks debug console - DO NOT CLOSE!");
         SetConsoleCtrlHandler(HandlerRoutine, TRUE);
         m_bIsConsole = true;
+        //(pecan 2010/10/20) start
+        HWND console_window_handle = GetConsoleWindow();
+        if (console_window_handle)
+        {
+            ShowWindow( console_window_handle, SW_HIDE );
+        }
+        //(pecan 2010/10/20) end
     }
     #endif
     // start the gdb process

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #14 on: November 30, 2010, 02:44:47 pm »
MSW: "Run to cursor" is enabled, runs the debugger and breaks the program at the cursor.

"Step Into" is enabled, runs the debugger but does not break the program.

Why is "Step Into" enabled before running the debugger?

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #15 on: November 30, 2010, 03:18:18 pm »
what about grouping all the debug related ones in a submenu Debug in the right click context menu (toggle breakpoint , run to cursor,  set next statement) ?
No :) this will make them harder to use...

Could we hide the remote console on MSW with something like the following:
Does stopping the debuggee works if the console is hidden? If it works I have nothing against it :)

"Step Into" is enabled, runs the debugger but does not break the program.

Why is "Step Into" enabled before running the debugger?
Debug log please...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline cbexaminr

  • Multiple posting newcomer
  • *
  • Posts: 104
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #16 on: November 30, 2010, 03:55:15 pm »
[deleted]

Offline Pecan

  • Plugin developer
  • Lives here!
  • ****
  • Posts: 2750
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #17 on: November 30, 2010, 07:22:00 pm »
Could we hide the remote console on MSW with something like the following:
Quote
Does stopping the debuggee works if the console is hidden? If it works I have nothing against it :)
Yep, the double bar on the debugger tool bar breaks just fine with the patch.

"Step Into" is enabled, runs the debugger but does not break the program.

Why is "Step Into" enabled before running the debugger?
Quote
Debug log please...
This log is from a MSW simple wxWidgets Hello world, a rebuild, then a hit on the "Step Into" button.

Debugger log
Code
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\temp\Test\
Adding source dir: C:\temp\Test\
Adding file: .\debug\Test.exe
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.0
Child process PID: 4520

Debugger debug log
Code
PATH=.;C:\Usr\Proj\wxWidgets2810\lib\gcc_lib;C:\Usr\mingw431\bin;C:\Usr\Proj\ImageCraft\ImageCraft_ARM\trunk\src\output;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Dell\Dell Wireless WLAN Card;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\usr\bin;C:\Program Files (x86)\CollabNet Subversion;C:\Program Files (x86)\TortoiseSVN\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Common Files\Adobe\AGL
Command-line: C:\Usr\mingw431\bin\gdb.exe -nx -fullname  -quiet -args ./debug/Test.exe
Working dir : C:\temp\Test\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\temp\Test/./debug/Test.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set print elements -1
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> source c:\Usr\Proj\cbDebug\trunk\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/temp/Test/
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 4768.0x2dc]

« Last Edit: November 30, 2010, 07:33:02 pm by Pecan »

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #18 on: November 30, 2010, 08:21:45 pm »
Pecan: Thanks this is a regression caused by the 17.7 patch. I'll look into it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #19 on: December 03, 2010, 05:11:50 pm »
BTW: Can someone try to reproduce this bug:

1. Start debugger
2. Break on some breakpoint
3. Show and dock the watches window
4. Select something in the editor
5. Drag and drop the selection in to the empty item at the bottom of the watches window

The result is that the drag'n'drop operation is cut not copy and the selected text is deleted from the editor.
I've successfully reproduced this bug on two linux machines:
1. gentoo amd64 unstable (gcc 4.4.5 + wxGTK 2.8.11)
2. fedora 8 amd64 inside vmware player (this machine was given to me and I don't know how updated it is)
Code
[root@localhost ~]# rpm -qa | grep wx
wxGTK-2.8.9-1.fc8
wxGTK-gl-2.8.9-1.fc8
wxGTK-devel-2.8.9-1.fc8
wxBase-2.8.9-1.fc8

[root@localhost ~]# uname -a
Linux localhost.localdomain 2.6.23.1-42.fc8 #1 SMP Tue Oct 30 13:18:33 EDT 2007 x86_64 x86_64 x86_64 GNU/Linux
[root@localhost ~]# cat /etc/redhat-release
Fedora release 8 (Werewolf)

(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #20 on: December 03, 2010, 07:32:48 pm »
BTW: Can someone try to reproduce this bug:

I can not reproduce it on debian 64-bit unstable, wx2.8.10, gcc 4.5.1.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #21 on: December 03, 2010, 08:42:29 pm »
Jens: I know, can you try on Suse, Fedora (if you have VMs for them)?
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Max

  • Guest
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #22 on: December 12, 2010, 05:13:38 pm »
Dear devs,

I'm reporting a ugly behavior (IMO) of the new debugger interface (I don't remember if I met the same issue with the old interface). I would say it's a bug...

I was debugging a code using a vector of double (20k element) and watching the array I've got two different behavior.

I the first case, the working one, the debugger log is saying

> whatis &x
type = vector *
>>>>>>cb_gdb:
> output x
{
  <_Vector_base> = {
    _M_impl = {
      <allocator> = {
        <new_allocator> = {<No data fields>}, <No data fields>},
      members of _Vector_base::_Vector_impl:
      _M_start = 0x1204d88,
      _M_finish = 0x122be80,
      _M_end_of_storage = 0x1244d88
    }
  }, <No data fields>}>>>>>>cb_gdb:
> cont

and everything works right, I'm able to see the popup window and to watch the array in the watch window.

In the second case I've got

> whatis &x
type = std::vector<double, std::allocator<double> > *
>>>>>>cb_gdb:
> pvector x
elem[0]: $1 = 0.97340000000000004
elem[1]: $2 = 1.0048000000000001
elem[2]: $3 = 1.0362
elem[3]: $4 = 1.0676000000000001
.
.
.

The output log from the debugger is listing all the elements, the cpu was going to 100% and CB seems frozen.

In both case x is a local std::vector<double>. The only difference is that the first 'x' belongs to the main program I was debugging, the second 'x' belongs to a method of a class contained in a static library I linked to the program.

Because it happens to put the cursor over a such variable, just moving the mouse, in some case I've got
the CB frozen even if I had't the intention to debug the vector.

This is ugly  :D

Hope this helps.

Max
 

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #23 on: December 12, 2010, 05:37:29 pm »
I've hit this bug, too... and it is a bit complex:

1. gdb doesn't know if a variable is initialized, so adding uninitialized vector to the watches cause CB to lock up (hovering on it, too)
2. cb doesn't limit the result set and I'm not sure if it could be fixed easily in the current non MI version of the plugin
3. it is present in the trunk version, because vector handling is not much different.

If you have time and energy you can look in stl-views-1.0.3.gdb for a way to limit the results returned from the pvector command.
Probably we should disable the usage of pvector in python enabled gdb's...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #24 on: December 13, 2010, 01:18:00 am »
1. gdb doesn't know if a variable is initialized, so adding uninitialized vector to the watches cause CB to lock up (hovering on it, too)

this is annoying bug, I have several bug report:

see:
http://sourceware.org/bugzilla/show_bug.cgi?id=12127
http://sourceware.org/bugzilla/show_bug.cgi?id=11407

and there are some discussion on the gdb maillist.
it is hard to detect a variable is initialized or not, even it was initialized, then later it can be destroyed. I have a patch to solve partially when showing the local variables patch. see:
http://sourceware.org/bugzilla/show_bug.cgi?id=11407#c33

but that doesn't solve every thing. I'm wondering how it was done in other debugger like MSVC debugger???
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #25 on: December 13, 2010, 08:26:34 am »
They use limits in their GUI, the same is possible with GDB/MI :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #26 on: December 13, 2010, 08:28:52 am »
They use limits in their GUI, the same is possible with GDB/MI :)
You mean MSVC debugger use limits when showing an uninitialized vector??
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #27 on: December 13, 2010, 09:26:13 am »
Their array control has a limit + scrolling...
Also they init variables with some magic numbers 0xfefefefe,0xabababab,0xcccccccc and it is possible that they use them to fix such problems...
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5910
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: The 27 November 2010 build (6863) DEBUGGER BRANCH version is out.
« Reply #28 on: December 13, 2010, 09:37:42 am »
Their array control has a limit + scrolling...
Also they init variables with some magic numbers 0xfefefefe,0xabababab,0xcccccccc and it is possible that they use them to fix such problems...
yes, I totally agree with you!!!
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.