C
Chuck Remes
Sorry for the long subject. I wanted to make sure folks interested in
WIN32OLE stuff saw it.
Anyway, I am doing some application automation on Windows using the
WIN32OLE classes. In this particular case, I have registered event
handlers for a bunch of possible events that may be generated by
another Windows application. I have tested about a dozen of these
handlers and all is well. However, I added one more and now when I
trigger the event that calls it, ruby crashes.
If I am using ruby 1.8.6 patch level 287, it generates a segfault and
writes the usual message:
It also gives me a line number in my code. This line corresponds to
this code:
WIN32OLE_EVENT.message_loop
I took the error message at face value and decided this was a ruby bug
so I upgraded to patch level 383. (For this installation I used the
one-click installer available from rubyinstaller.org, preview 2).
It still crashes but now it doesn't give me any code line or write any
message at all.
I'm not well versed in Windows programming so I don't really know how
to debug this. Here is what I have tried:
1. I've narrowed the "cause" down to the line of code that generates
the event that the handler will get on the next call to
WIN32OLE_EVENT.message_loop. If I comment it out, the program
continues to run. With it in, the program crashes.
The line in question is calling a method on a WIN32OLE COM object that
was previously retrieved via WIN32OLE.new. The method called generates
a callback event after it finishes processing. This same COM object is
also used for making other method calls that are all succeeding just
fine.
2. I thought that perhaps I had a bug in my event handler code. I
commented it out. The crash still occurs.
This leads me to believe that the event being received is causing the
crash. I have *no idea* how to get deeper on this without getting the
ruby C source and mucking about inside the #message_loop code.
Anyone have any ideas on how I can solve this? If you need more
information, let me know. At this point this crash is a showstopper
for me because I *need* to be able to process the event that is
causing the crash.
cr
WIN32OLE stuff saw it.
Anyway, I am doing some application automation on Windows using the
WIN32OLE classes. In this particular case, I have registered event
handlers for a bunch of possible events that may be generated by
another Windows application. I have tested about a dozen of these
handlers and all is well. However, I added one more and now when I
trigger the event that calls it, ruby crashes.
If I am using ruby 1.8.6 patch level 287, it generates a segfault and
writes the usual message:
It also gives me a line number in my code. This line corresponds to
this code:
WIN32OLE_EVENT.message_loop
I took the error message at face value and decided this was a ruby bug
so I upgraded to patch level 383. (For this installation I used the
one-click installer available from rubyinstaller.org, preview 2).
It still crashes but now it doesn't give me any code line or write any
message at all.
I'm not well versed in Windows programming so I don't really know how
to debug this. Here is what I have tried:
1. I've narrowed the "cause" down to the line of code that generates
the event that the handler will get on the next call to
WIN32OLE_EVENT.message_loop. If I comment it out, the program
continues to run. With it in, the program crashes.
The line in question is calling a method on a WIN32OLE COM object that
was previously retrieved via WIN32OLE.new. The method called generates
a callback event after it finishes processing. This same COM object is
also used for making other method calls that are all succeeding just
fine.
2. I thought that perhaps I had a bug in my event handler code. I
commented it out. The crash still occurs.
This leads me to believe that the event being received is causing the
crash. I have *no idea* how to get deeper on this without getting the
ruby C source and mucking about inside the #message_loop code.
Anyone have any ideas on how I can solve this? If you need more
information, let me know. At this point this crash is a showstopper
for me because I *need* to be able to process the event that is
causing the crash.
cr