Actually the & is not the cause, the problem also arises without it.

System: Windows 2000 5.00.2195 SP4, AMD Athlon

The problem does not happen if C::B is closed and then re-started before the shortcut is used, only if it is used immediately after being defined.

New observation: the Help menu is not specifically the cause. Doing Alt-F for the File menu followed by the 'F' key again (even if there is no particular menu option for this letter) also crashes CB.

Tested on today's nightly build (CB_20060219_rev2040_win32.7z) too and obtained the same result.

Right, it has nothing to do with the help menu, neither the help plugin itself.

I tried Alt+F F and got the crash immediately.

It's incorrectly assigned to me with no way to change it.

I disabled all plugins except compile; this still happens.

winXPsp2 svn 2051

(gdb) shows the following bt

Program received signal SIGSEGV, Segmentation fault.

0x7c910aa8 in wcsncpy () from ntdll.dll

(gdb) bt

#0 0x7c910aa8 in wcsncpy () from ntdll.dll

#1 0x0000000b in ?? ()

#2 0x0022e994 in ?? ()

#3 0x0022e978 in ?? ()

#4 0x77d6735e in USER32!GetMenuItemInfoW ()

from C:\WINDOWS\system32\user32.dll

#5 0xffffffff in ?? ()

#6 0x00f9ef50 in ?? ()

#7 0x0000000b in ?? ()

#8 0x0022e9dc in ?? ()

#9 0x0022e9dc in ?? ()

#10 0x00000004 in ?? ()

#11 0x0022e9c4 in ?? ()

#12 0x77d67294 in USER32!GetMenuItemInfoW ()

from C:\WINDOWS\system32\user32.dll

#13 0x00f9eb68 in ?? ()

#14 0x00000004 in ?? ()

#15 0x00000001 in ?? ()

#16 0x0022e994 in ?? ()

#17 0x0000001d in ?? ()

#18 0x00000030 in ?? ()

#19 0x000001f0 in ?? ()

#20 0x00000000 in ?? () from

---Type <return> to continue, or q <return> to quit---

#21 0x00000000 in ?? () from

#22 0x00000000 in ?? () from

#23 0x00000000 in ?? () from

#24 0x00000000 in ?? () from

#25 0x00000000 in ?? () from

#26 0x00000000 in ?? () from

#27 0xffffffff in ?? ()

#28 0x0000000c in ?? ()

#29 0x00000000 in ?? () from

#30 0x0022ea24 in ?? ()

#31 0x1011212c in wxmsw26u_gcc_cb!_ZN8wxWindow14HandleMenuCharEil ()

from c:\Usr\Proj\cbBeta\trunk\src\devel\wxmsw26u_gcc_cb.dll

Previous frame inner to this frame (corrupt stack?)

(gdb)

looks like a corrupt stack in wxWidgets, or the bt cant continue?

pecan

Is this the bug?? Looks like it wasn't fixed until Jan 13 this year.

We might still have it in 2.6.1

http://lists.wxwidgets.org/cgi-bin/ezmlm-cgi?8:mss:86773:200601:omahhemelnkgfmllfnla

This appears to be happening when the accelerator is _NOT_ defined in the menu. Alt F F in the file menus, as well as other menus crash when the accelerator is not defined. Defined accelerators work fine in winXPsp2 svn2051.

HandleMenuchar() in window.cpp should never invoking windows. It should be passing back wxNOT_FOUND.

Will trace through this in the afternoon.

-pecan-

I traced thru the window.cpp::HandleMenuChar() code. It is, in fact, causing this err. MenuItemInfo.dwTypeData is not being cleared after its filled to 0xffffffff by a previous call to ::getMenuItemInfo(). It's then used as a memory address on the next call, causing the segfault. I cleared it by hand on each call, the menus then worked fine. But I don't know how to fix this for C::B. Its a wxWidgets bug.

Zeitlin says he fixed this. I'd guess in 2.6.3, 'cuz it sure ain't fixed in 2.6.2

info:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/winui/winui/windowsuserinterface/resources/menus/menureference/menustructures/menuiteminfo.asp

To retrieve a menu item of type MFT_STRING, first find the size of the string by setting the dwTypeData member of MENUITEMINFO to NULL and then calling GetMenuItemInfo. The value of cch+1 is the size needed. Then allocate a buffer of this size, place the pointer to the buffer in dwTypeData, increment cch, and call GetMenuItemInfo once again to fill the buffer with the string. If the retrieved menu item is of some other type, then GetMenuItemInfo sets the dwTypeData member to a value whose type is specified by the fType member.

-pecan-

This bug is fixed in 2.6.3-RC1 with the following line:
        mii.cch = 0;

in the window.cpp code causing Windows to reset  MenuItemInfo.dwTypeData:

   // find if we have this letter in any owner drawn item
    const int count = ::GetMenuItemCount(hmenu);
    for ( int i = 0; i < count; i++ )
    {
        // previous loop iteration could modify it, reset it back before
        // calling GetMenuItemInfo() to prevent it from overflowing dwTypeData
        mii.cch = 0;

        if ( ::GetMenuItemInfo(hmenu, i, TRUE, &mii) )
        {
...
-pecan-

Now that 2.6.3 is out can this bug be closed?

Closing bug report.

It is a wxWidgets problem fixed in wxWidgets 2.6.3 (which will be the official version for Code::Blocks).