31
Programming / Re: DOSBox-x - infinite loop in configure/make
« on: November 07, 2024, 09:01:42 am »
In DOSBOX, drive is a char array, but on DOSBOX-X it seems to be a struct or object. So, there is some work to do.
OS2World.com Forum is back !!!
Remember to visit OS2World at:
http://www.os2world.com
This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Hi Lars@Pete: Sorry, I was sick. You got a response ;-)
The SDL package in use is SDL-1.2.15-5.oc00.pentium4.rpm (from netlabs-rel) which provides the sdl120.dll required by dosbox074_2020-11-04.wpi which seems to be the latest release.
No response to my email to Jochen
Regards
Pete
<ul>
<li>WC_BUTTON<br/>
Consists of buttons and boxes that the operator can select by clicking the pointing device or using the keyboard. These messages are described in <a href="...">Button Control Window Processing.</a>
</li>
...
</ul>
you can also try to wrap the explanation in <p> making it its own paragraph, then you don't need the <br/>. But I don't know ATM how that would look.[..]Do you mean, Dive itself spins up thread. I myself wait for CC to call me for an update without doing the blit in a thread.
On all occasions, the trap does not happen in the main thread. I suspect some problem with the File Dialog obscuring part of the window drawn to by DIVE and the DIVE thread trapping rather than "WinFileDlg". In all cases, it is running out of stack.
This is not correct.Actually, Lars is correct. 'args' is the setup struct from ClassiCube, and filters is an array of pointers (more acurate a pointer to pointer
)
1) Since the trap occurs in "WinRequestMutexSem" (which you are apparently not directly calling from anywhere), I suspect it has something to do with calling "WinSetVisibleRegionNotify" before calling "WinFileDlg" and after calling "WinFileDlg". My gut feeling is that it is a problem surrounding the call to "WinFileDlg" with these calls. As a test, I'd remove thatI added these calls just recently. With or without them the app crashes.
2) "args->filters" is effectively a PAPSZ pointer, that is, a pointer to an array of pointers where the last pointer in the variable array is a NULL pointer, see the example code for the Windows implementation:You are correct, but that's why I did '*(args->filter)' which let's me copy the first string to fileDialog.szFullFile. Also, I have used 'char szFullFile[CCHMAXATH] = "*.*"', and copied it to fileDialog.szFullFile. The app still crashes.
[..]
1.) Yes, because WinFileDlg does not return, until you close the dialog. All samples would not work with local variables. Also, I tested that code with a local variable in a different script program and there it works, even without explicitely setting 2.) + 3.)Another problem, I can't solve, is that the eCosoft Runtime's file dialog crash with the following codeCode: [Select]FILEDLG fileDialog;I uninstalled the runtimes. Nothing crashes, everything is fine. I reinstalled the newest runtime. The apps crashes again.
HWND hDialog;
memset(&fileDialog, 0, sizeof(FILEDLG));
fileDialog.cbSize = sizeof(FILEDLG);
fileDialog.fl = FDS_HELPBUTTON | FDS_CENTER | FDS_OPEN_DIALOG;
fileDialog.pszTitle = (PSZ)args->description;
memcpy(fileDialog.szFullFile, *(args->filters), CCHMAXPATH);
hDialog = WinFileDlg(HWND_DESKTOP, hwndFrame, &fileDialog);
if (fileDialog.lReturn == DID_OK) {
}
Other apps, like EPM, have no problems. I also replicated the example for WinFileDlg, but it's all the same.
My popup log is attached.
1) are you sure that args->description will be a valid address across the call to WinFileDlg ?
2) What did you set fileDialog.pszOKButton to ?
3) What did you set fileDialog.pszlDrive to ?
In particular for the latter, the doc does not say that you can set it to a NULL pointer. Even if the code example implies differently. And even if the default dialog procedure gracefully handles NULL pointers for certain arguments, then the eCosoft runtime dialog procedure override might not.
Exception codes are documented in the OS/2 Debugging Handbook (sg244640.inf) and the Control Program Guide and Reference (GPG&R)
Both annotate the value differently. Given c0000005, you need to search for 0c0000005h in the Debugging Handbook and for 0xc0000005 in the CPG&R.
As Dave noted, you need to expand the per thread stack for TID 0xa. You can use LIBC_THREAD_MIN_STACK_SIZE to set the minimum at runtime or, assuming that ClassiCube is using pthreads, you can adjust the compile time values by modifying the code that eventually invokes pthread_attr_setstacksize()
Note that while you can get stack overflow if the stack is too small, you can also get stack overflow if the code recurses unexpectedly. A popuplog is typically not going to tell why the stack overflow happened. This requires an exceptq report or a process dump file.
BTW, are your sources available anywhere?
This looks like stack overflow in a secondary thread (TID 0xa). If possible, try rebuilding with larger thread stacks.Thanks for the hint, but even with a stacksize of 81920000 the dialog crashes the app (and also the IBM debugger, BTW).
Steven