Jump to content

AutoIt Beta 3.3.1.1


Recommended Posts

I upgraded to the AutoIT 3.3.1.0 beta a few days ago and upgraded to 3.3.1.1 yesterday.

Since upgrading to 3.3.1.0 from the production version, I've been attempting to resolve an AutoIT crash that I began encountering after the initial upgrade to 3.3.1.0 (upgrading to 3.3.1.1 made no difference w.r.t. the crash).

I'm in kind of a pickle on this one: the application is very large and uses inter-process communications -- I can only run (with any ease) the failing script as an exe, and the crash appears to be related to a timing issue. As I add more traces to the subject functions, the crash becomes difficult to cause. I've tried to duplicate the scenario in smaller, independent scripts, but have not been able to replicate the problem.

I'm questioning whether the change introduced to the application from the upgrade may be related to the beta changes in the AdLib function (the application itself is unchanged and never crashed in the production version).

What I know for sure is that the crash is happening because a UDF executed via AdLibRegister is interrupted by a UDF initiated due to a mouse move. I realize this behavior is the same as before: a UDF driven by a mouse event could always interrupt a UDF driven by AdLib, but here's a question: Can an AutoIT function itself be interrupted? In my case, the UDF driven by the ADLibRegister executes another ADLibRegister. This UDF is (and should be) interrupted by a UDF driven via a mouse move. Is the ADLibRegister function itself interruptible?

The only information I have is from the Windows Event Log -- it shows the application fails at an offset of 4d65a. I don't know if this has any meaning, but I've crashed over 20 times and it is ALWAYS at offset 4d65a).

Any tips on how I may debug this one would of course be very much appreciated.

Link to comment
Share on other sites

If you run it through SciTE then in console you will have something like this (red color):

!>17:51:48 AutoIT3.exe ended.rc:-1073741819

Or find error code in report. Post that. Maybe just to narrow it down a bit.

Thanks for the reply...the problem is, I can't easily run it in SciTE or in non-compiled form; otherwise I could get the script line where it's failing. I may have to make the necessary changes necessary to run it in non-compiled form, but that's more work than one may think! If I put a trace (log to file) after every line in the failing UDF, it doesn't crash because apparently the timing is different.
Link to comment
Share on other sites

If you run it through SciTE then in console you will have something like this (red color):

!>17:51:48 AutoIT3.exe ended.rc:-1073741819

Or find error code in report. Post that. Maybe just to narrow it down a bit.

That's useless information and it's information that can be retrieved from the crash dialog anyway. There is really no useful information that can be given to us from a crash. Our release builds intentionally do not have any debugging information for size reasons.

pdaughe, that doesn't sound very hard to reproduce. An Adlib setup to run very often and whatever other event you have should cause it to happen almost instantly. Assuming, of course, that is the problem.

Link to comment
Share on other sites

That's useless information and it's information that can be retrieved from the crash dialog anyway. There is really no useful information that can be given to us from a crash. Our release builds intentionally do not have any debugging information for size reasons.

pdaughe, that doesn't sound very hard to reproduce. An Adlib setup to run very often and whatever other event you have should cause it to happen almost instantly. Assuming, of course, that is the problem.

Thanks Valik -- I have tried to replicate it, but I'll pursue this approach as you suggest. By the way, thanks for all the hard work you obviously put in; there were some very nice enhancements in the beta.
Link to comment
Share on other sites

So you admit that you intend to reverse engineer AutoIt to debug the issue?

I'm a legalist. I would newer* do what's forbidden.

Let's not continue this conversation because the meaning is lost.

edit:

* never

Edited by trancexx

♡♡♡

.

eMyvnE

Link to comment
Share on other sites

I'm a legalist. I would newer do what's forbidden.

Let's not continue this conversation because the meaning is lost.

If you are a legalist as you say then I think now is a good time to go and re-read the license agree that came with AutoIt 3.3.1.1.
Link to comment
Share on other sites

Back on topic... :)

@pdaughe: I couldn't reproduce with this:

#include <WindowsConstants.au3>
#include <GuiConstantsEx.au3>

$hGUI = GUICreate("Test", 300, 300)
$ctrlEdit = GUICtrlCreateEdit("", 20, 40, 260, 220)
GUISetState()

GUIRegisterMsg($WM_MOUSEMOVE, "_WM_MOUSEMOVE")

AdlibRegister("_AdLibMain", 100)

Do
Until GUIGetMsg() = $GUI_EVENT_CLOSE

Func _WM_MOUSEMOVE($hWndGUI, $MsgID, $wParam, $lParam)
    Local $sMsg = "$hWndGUI = " & $hWndGUI & @CRLF
    $sMsg &= "$MsgID = " & $MsgID & @CRLF
    $sMsg &= "$wParam = " & $wParam & @CRLF
    $sMsg &= "$lParam = " & $lParam & @CRLF
    ControlSetText($hGUI, "", $ctrlEdit, $sMsg)

    Return $GUI_RUNDEFMSG
EndFunc  ;==>WM_MOUSEMOVE

Func _AdLibMain()
    Local $iTimer = TimerInit()
    Do
    Until TimerDiff($iTimer) >= 80
EndFunc  ;==>_AdLibMain

The _AdLibMain() function should be busy about 80% of the time, so at least some WM_MOUSEMOVE events are likely to interrupt it if you move the mouse around on the GUI.

Can you mod it just enough to see your symptoms? A minimized reproducer would make it much easier to figure out what's happening.

:)

Valuater's AutoIt 1-2-3, Class... Is now in Session!For those who want somebody to write the script for them: RentACoder"Any technology distinguishable from magic is insufficiently advanced." -- Geek's corollary to Clarke's law
Link to comment
Share on other sites

Actually it doesn't even need to be small. All I ask really is that it:

  • Reproduces the problem reliably (for example, you tell me to start the script and move the mouse and it will crash within seconds).
  • Doesn't require external software.
  • Doesn't make changes to the system.
The smaller the better, of course, but all I really need to see is whats crashing and I should be able to fix it from there.
Link to comment
Share on other sites

PSaltyDS -- thanks very much for looking at this. Your simple script is similar to my test script -- except that I AdLibRegister and AdLibUnRegister like crazy! I appreciate your willingness to help.

Valik -- FYI I have tested AdLibRegister/UnRegister exhaustively, interrupting driven functions with mouse and hotkey events. AutoIT has performed impeccably so you're right -- there must be something else going on; I'll find it, eventually :)

By the way, the documentation for AdLibRegister could note that the frequency for an already register function can be changed simply by executing another AdLibRegister with the new frequency. That may have been true with the original AdLib function and I just never realized it...

Link to comment
Share on other sites

Our release builds intentionally do not have any debugging information for size reasons.

Maybe bad question from me as laik at debuggers:

Is it possible to create MAP file containing debug information externally only for users solving some big problems?

I mean something like Koda does - there is standalone MAP file for this.

Link to comment
Share on other sites

Maybe bad question from me as laik at debuggers:

Is it possible to create MAP file containing debug information externally only for users solving some big problems?

I mean something like Koda does - there is standalone MAP file for this.

Well, in theory we could simply do that for sporadic problems like this. I could simply compile a version and let pdaughe crash that. There's not really a general need for a MAP file, though.
Link to comment
Share on other sites

Well, in theory we could simply do that for sporadic problems like this. I could simply compile a version and let pdaughe crash that. There's not really a general need for a MAP file, though.

In this case there must be assistance of developers for findind detail information.

So I think it would be better to have such MAP file available for download (not included in standard AutoIt but placed somewhere in Download section).

Link to comment
Share on other sites

In this case there must be assistance of developers for findind detail information.

So I think it would be better to have such MAP file available for download (not included in standard AutoIt but placed somewhere in Download section).

I do not think users need a MAP file.
Link to comment
Share on other sites

Indeed users do not need a MAP file. All I need is the offset of the crash and I can figure out which function it was in. Users do not need the file for that.

pdaughe, if you are willing, I can give you a freshly compiled version of 3.3.1.1's AutoItSC.bin. I will, of course, have the MAP file for that version. You can run it until it crashes and then tell me the offset. I might be able to work something out from there.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...