sorrow@oak.circa.ufl.edu (06/03/91)
Hi all. I have been using my own mouse routines and installed my own mouse interrupt handler. Here is the problem: 1. I am using a 386/33 using Borland C++ (BC /X, not BCX). 2. When running Logitech Mouse Driver 5.00 I have found that when I run my program I get a "Stack Overflow!" error. I have stack checking enabled. This happens on my 386 but not on a 286. 3. This does not happen using Logitech Mouse 4.00. 4. The stack overflow occurs the SECOND I TOUCH THE MOUSE after my routines to install my mouse handler (call back function) are executed. 5. The machine will work inconsistently with stack checking off. So, the question is: Is there a bug with Logitech 5.00 that I am not aware of? If so, why do my other mouse programs (Eye of the Beholder, Windows 3.0, BC++, etc.) work with the driver and my programs die? Is there something that I am missing here fundamentally? And I own the Microsoft Mouse PRogrammer's Reference, but it is the worst programming book I have yet to lay eyes on. *sigh* This is real annoying. Any replies, posted or mailed, would be appreciated. Brian /* Brian Hook -- MS-DOS Programmer for Contract ----------------------------------------------------------------- "I was in the kitchen, Seamus, that's my dog, was outside....and buried ALIVE....fritter and waste...but this one goes to 11!....anymore of that plutonium nyborg?....SNOW TIME!....This is home...this is Mean Street.. */
jwbirdsa@amc.com (James Birdsall) (06/04/91)
In article <00949912.601AB080@MAPLE.CIRCA.UFL.EDU> sorrow@oak.circa.ufl.edu writes: >Hi all. I have been using my own mouse routines and installed my own mouse >interrupt handler. Here is the problem: > >1. I am using a 386/33 using Borland C++ (BC /X, not BCX). >2. When running Logitech Mouse Driver 5.00 I have found that when I run my >program I get a "Stack Overflow!" error. I have stack checking enabled. >This happens on my 386 but not on a 286. >3. This does not happen using Logitech Mouse 4.00. >4. The stack overflow occurs the SECOND I TOUCH THE MOUSE after my routines >to install my mouse handler (call back function) are executed. >5. The machine will work inconsistently with stack checking off. > >Is there a bug with Logitech 5.00 that I am not aware of? If so, why do >my other mouse programs (Eye of the Beholder, Windows 3.0, BC++, etc.) work >with the driver and my programs die? Is there something that I am missing >here fundamentally? It sounds like you have two separate problems. Stack checking, and something else. A fact that is mentioned in passing in the manual under setvect(): interrupt routines won't work if you have stack checking turned on. Which makes sense; the stack checker assumes that the current stack is your program's stack. Since an interrupt handler can be called from anywhere, the current stack may be anything, causing the stack checker to freak out. The mouse call-back routine is called from inside the mouse driver's hardware interrupt, so the call-back occurs asynchronously. Actually, that suggests a couple more ideas. Other things that could be happening: 1) Are you declaring a lot of local variables? You may be intermittently overflowing somebody else's stack, munging whatever was below the stack. 2) Are you accessing global variables, or calling other functions in your program which do? Since it's being called asynchronously, DS may not be pointing to your data segment, in which case you will be reading garbage and writing over somebody else's data (or code!). Both of these problems would cause intermittent crashes. As to why it works under the older driver and not the newer, I don't know. The problem may be entirely different, but this gives you someplace to start. -- James W. Birdsall WORK: jwbirdsa@amc.com {uunet,uw-coco}!amc-gw!jwbirdsa HOME: {uunet,uw-coco}!amc-gw!picarefy!jwbirdsa OTHER: 71261.1731@compuserve.com "The OS shouldn't die every time the controller drools on a sector." -- a sysop =========== "For it is the doom of men that they forget." -- Merlin ===========
sorrow@oak.circa.ufl.edu (06/04/91)
It seems that I was a tad bit ambiguous with my post about the differences. However, in the time since that last post I was at work and working on this problem. Here is a quick summary: 1. I now get the "Stack overflow!" message on all machines some of the time. 2. I am using Borland C++ with stack checking enabled, large model. 3. I am using int 0x33, function 0x0C to install my own call mask and interrupt handler ( I am NOT replacing int 0x33). 4. It is not a problem with my interrupt handler, since it is NEVER reached. I set a break point at the beginning of it, touch the mouse, BOOM, stack overflow. 5. I just ordered the Logitech Mouse Programmer's Toolkit and pray to God that it is better than that Mouse Programmer's Reference from MicroSlough. I downloaded Logitech Mouse.COM 5.01 and it solved the problem for about 45 minutes when it started happening again. Reboot, still happened. I have tried Logitech 3.42, 4.00, 5.00, and 5.01. I get stack overflow with all but 3.42. NOW, I am positive it is not a stray pointer somewhere since the code consists of nothing more than installing the handler, showing the mouse, then exit on a keyclick. And the code is not outright broken, since some times, rather arbitrarily, it works fine, exits fine, etc. Other times, I just bump my desk and the program explodes. Hmmm... Any help would be appreciated once again, and thanks to those that sent the first wave of replies :-) Brian /* Brian Hook -- MS-DOS Programmer for Contract ----------------------------------------------------------------- "I was in the kitchen, Seamus, that's my dog, was outside....and buried ALIVE....fritter and waste...but this one goes to 11!....anymore of that plutonium nyborg?....SNOW TIME!....This is home...this is Mean Street.. */
sorrow@oak.circa.ufl.edu (06/04/91)
In article <1991Jun3.173405.6109@amc.com>, jwbirdsa@amc.com (James Birdsall) writes: |> It sounds like you have two separate problems. Stack checking, and |>something else. A fact that is mentioned in passing in the manual under |>setvect(): interrupt routines won't work if you have stack checking |>turned on. Which makes sense; the stack checker assumes that the current |>stack is your program's stack. Since an interrupt handler can be called |>from anywhere, the current stack may be anything, causing the stack |>checker to freak out. The mouse call-back routine is called from inside |>the mouse driver's hardware interrupt, so the call-back occurs |>asynchronously. A-ha! That could very well be it. See, where I have a problem is that no reference books that I have found tell you how to modify things in your interrupt handler. And I was under the impression that the stack for my call back routine was part of the global stack, and that the interrupt itself had its own. No where is any documentation very clear on this. |> |> Actually, that suggests a couple more ideas. Other things that could be |>happening: |> |> 1) Are you declaring a lot of local variables? You may be intermittently |>overflowing somebody else's stack, munging whatever was below the stack. No, I am not declaring a lot. All in all, I'd say I have less than 5 local variables. |> |> 2) Are you accessing global variables, or calling other functions in |>your program which do? Since it's being called asynchronously, DS may |>not be pointing to your data segment, in which case you will be reading |>garbage and writing over somebody else's data (or code!). Yes, I am accessing a single global struct (my event queue). Now, originally I had used a friend's code which stored the address of my queue in an unused interrupt vector, then in the interrupt routine I would grab that address and use it as a pointer to the queue. However, I was having some problems with it so just tried using a global variable. Worked wonderfully. So this could be the problem, huh? Anything in particular to watch for? Should I return to using the indirection via vector table. Brian /* Brian Hook -- MS-DOS Programmer for Contract ----------------------------------------------------------------- "I was in the kitchen, Seamus, that's my dog, was outside....and buried ALIVE....fritter and waste...but this one goes to 11!....anymore of that plutonium nyborg?....SNOW TIME!....This is home...this is Mean Street.. */
docbrain@netmbx.UUCP (Frank Seidinger) (06/05/91)
sorrow@oak.circa.ufl.edu writes: >Hi all. I have been using my own mouse routines and installed my own mouse >interrupt handler. Here is the problem: >1. I am using a 386/33 using Borland C++ (BC /X, not BCX). >2. When running Logitech Mouse Driver 5.00 I have found that when I run my >program I get a "Stack Overflow!" error. I have stack checking enabled. >This happens on my 386 but not on a 286. >3. This does not happen using Logitech Mouse 4.00. >4. The stack overflow occurs the SECOND I TOUCH THE MOUSE after my routines >to install my mouse handler (call back function) are executed. >5. The machine will work inconsistently with stack checking off. I had to do the same thing in Turbo Pascal. So I found out, that it was not to do with some support of assemby code. If you are familar with assembly, drop me a mail and I will send you my complete solution. For now here are some hints: The new handler has to end with an RET, because it is called from the mouse driver via CALL FAR. Therefore neither the deklaration as an Interrupt Procedure (I'm speaking Turbo Pascal, but should be similar in C), nor a normal deklaration will work. The DS register has to be set up for using with your program. The Turbo Linker and other will help you with an predefined symbol called DATA, that can be used with an assembler. The code can be linked with your program using the object- file method. The reason for that is mentioned by an other writer (asynchronous call). After setting up the DS register and preserving the other ones needed, you are able to call your own procedures from within the interrupt. Also here you will be helped by the linker. You only have to deklare the procedures you want to use from within your handler as externals in the assembly code. And of course you have to disable stack and range checking. hope this helps, Frank. ---------------------------------------------------------------------- >>>>>>>>>>>>>>>>>> Wenn alles egal ist, Budweiser ! <<<<<<<<<<<<<<<<< ---------------------------------------------------------------------- * \/|\/ _ * * * \/\|/\/ / \ * e-mail docbrain@netmbx.in-berlin.de * * \|/ | @ | * docbrain%netmbx@db0tui6.bitnet * * | | A| * docbrain%netmbx@tub.uucp * ----------------------------------------------------------------------