Crash in DrRacket 6.5 on Windows

[blerner]

I don't have a fully reliable repro for this bug, but it seems to occur more often when I use a two-fingered swipe gesture to try to scroll the interactions pane. I'm using DrRacket 6.5, x64, on Win7x64. In any case, something happens and I get a console window pop up that says:

 send: no such method
   method name: is-floating?
   class name: wx-editor-canvas%

The console window is not closable, DrRacket is unresponsive (can't save, can't change focus, etc.), and my laptop fan kicks in (so I think it's going into some infinite loop). The only solution is to forcibly close the main DrRacket window and ask Windows to force-quit the program.

Since I've managed to trigger this a few times in the past few minutes (again, it seems to be while I'm trying to scroll the interactions pane), is there any debug-logging I could enable to get you a more informative report?

[rfindler]

Is that the entire error message? If not, then if you click on the window you should get a menu item that lets you copy its contents. (I'm hopeful that the stack will be illuminating, which generally shows up right below the text you posted.)

[blerner]

Nope, sorry, it was literally just those three lines, nothing else at all. When I managed to crash it again, and looked in Process Explorer to try to get stacks, there wasn't much there either. There were two threads that seemed to be active: one was using an entire core, and its entire stack was

ntdll.dll!NtWaitForSingleObject+0xa
KERNELBASE.dll!WaitForSingleObjectEx+0x9c
libracket3m_a078zk.dll!scheme_need_wakeup+0x941

and the other thread was using ~1/4 of a core, and its entire stack was

ntdll.dll!NtWaitForSingleObject+0xa
KERNELBASE.dll!WaitForSingleObjectEx+0x9c
libracket3m_a078zk.dll!scheme_need_wakeup+0xa51 <<== only this address is different

There were four other threads with the same stacks (last offsets are 0xa7e, 0x25e1, 0x2605, and 0x2605 again), and one other thread with an interesting stack (but zero CPU usage):

ntdll.dll!ZwWaitForMultipleObjects+0xa
KERNELBASE.dll!GetCurrentProcess+0x40
kernel32.dll!WaitForMultipleObjectsEx+0xb3
USER32.dll!GetScrollBarInfo+0x1dd
USER32.dll!MsgWaitForMultipleObjectsEx+0x2e
USER32.dll!MsgWaitForMultipleObjects+0x20
libracket3m_a078zk.dll!scheme_collapse_win_fd+0x88e
libracket3m_a078zk.dll!scheme_symbol_name+0x25478
libracket3m_a078zk.dll!scheme_thread_block+0xb86
libracket3m_a078zk.dll!scheme_block_until+0x197
libracket3m_a078zk.dll!scheme_block_until+0x871
libracket3m_a078zk.dll!scheme_sync_enable_break+0x9c
libracket3m_a078zk.dll!scheme_tls_delta
libracket3m_a078zk.dll!scheme_do_eval+0x2447
libracket3m_a078zk.dll!scheme_tls_delta
libracket3m_a078zk.dll!scheme_do_eval+0x39fe

[blerner]

Some more info: I managed to trigger this crash by having an empty file with #lang at-exp racket, then in the interactions pane running (map display (range 1 1000)), and just flicking the scrolling around in the interactions and definitions panes. Hadn't loaded any files or done anything tricky, and crashed DrRacket in under 10 seconds. Again, I only have that three-line console window output, and again I have only seven threads running. One of them is slightly new:

ntdll.dll!ZwReadFile+0xa
KERNELBASE.dll!ReadFile+0x7a
kernel32.dll!ReadFile+0x59
libracket3m_a078zk.dll!scheme_need_wakeup+0x2605

but again that thread is using 0% CPU. The most active thread has changing stacks: sometimes its entire stack is libracket3m_a078zk.dll!scheme_free_all+0xef, and other times it's libracket3m_a078zk.dll!scheme_break_kind_thread+0x25d, and still other times it's the stack I mentioned initially.

Interestingly, while DrRacket is frozen, my two-fingered scrolling gesture doesn't work in any other program, either, as if it's stolen the mouse-scrolling focus. Once I kill DrRacket, scrolling works again.

[rfindler]

I'm not sure, but the fix may be to change the wx on this line:

https://github.com/racket/gui/blob/master/gui-lib/mred/private/wx/win32/frame.rkt#L435

to (is-a? wx frame%)

This looks windows-specific too.

[etiktin]

I also encountered this issue using v6.10 on Windows 10 Creators update. It happened 2 or 3 times today, and in all of those cases I was trying to scroll using my laptop's touch-pad. Each time seeing a console screen with the 3 lines the OP mentioned (you need to restart Dr.Racket to continue working).

Some extra info that might be of interest:

• Scrolling using the touch-pad doesn't really work for me in Dr.Racket, even though it works everywhere else (other text editors, web browsers etc.). If I try to do the scroll motion (swipe up/down with 2 fingers) enough times, you eventually see some small delayed movement in the correct direction, but it's not really usable
• Scrolling with an external mouse works properly
• My laptop also has a touch-screen. Scrolling trough the touch-screen, works properly

Edit: it happened again, and this time I managed to capture a screenshot

[dtrailin]

I am also having the same issue on Windows 10 in DrRacket 6.10.1 after running a program and scrolling through the results.

[JennHsin]

Hi,
So I recently just downloaded DrRacket version 7 on my Windows10 64x64, and this problem seems to be occurring with my touch pad too. When I open my lecture doc on DrRacket, as soon as I run the code and scroll through the results with my touch pad, the program crashes and the same little window pops up, and I would have to forcibly quiz the program using Windows.

I submitted this bug to DrRacket already, but I thought I would probably get an answer from here faster.

Thank you!

[rfindler]

@blerner @etiktin @dtrailin @JennHsin : I believe there have been a bunch of improvements to scrolling since the time when you were reporting this error and I'm not able to reproduce this anymore (although I could not reproduce it in 6.10.1 just now either), nor are we getting reports. Is anyone still seeing the problem?

[etiktin]

@rfindler I haven't used DrRacket in a while, so I can't confirm if the issue is fixed.
I think closing this issue is fine. If someone encounters it in the future, they can open a new issue with updated details.

[blerner]

I haven't seen this issue in quite a while, either.

[rfindler]

Thanks @blerner @etiktin !