ClassiCube porting thread

[Jochen Schäfer]

Sure, I read the WM_CHAR help, but there is no clue, why this happens only for captured windows.
While captured, I still see that F4 is released with ALT pressed. Weird.

[Jochen Schäfer]

Another problem, I can't solve, is that the eCosoft Runtime's file dialog crash with the following code

Code: [Select]

FILEDLG fileDialog;
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) {
}
I uninstalled the runtimes. Nothing crashes, everything is fine. I reinstalled the newest runtime. The apps crashes again.
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.

[Steven Levine]

This looks like stack overflow in a secondary thread (TID 0xa).  If possible, try rebuilding with larger thread stacks.

Steven

[Jochen Schäfer]

This looks like stack overflow in a secondary thread (TID 0xa).  If possible, try rebuilding with larger thread stacks.

Steven

Thanks for the hint, but even with a stacksize of 81920000 the dialog crashes the app (and also the IBM debugger, BTW).
There must be something else be going on.

BTW, do you know where to find this SYSxxxx code?

[Dave Yeo]

There's %LIBC_THREAD_MIN_STACK_SIZE% to specify the minimum stack size for new threads. Default is 4096 bytes.
Seems there's a flag too but can't remember it.

[Steven Levine]

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?

[Jochen Schäfer]

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?

Well, here we go. I knew, I was missing something, like that app stack is not thread stack.
Yes, I use pthreads at the moment, and I saw that ClassiCubes implementation will use some constant values. I will have to #ifdef them, I suppose.

My code is here, but it's not the most recent: https://github.com/josch1710/ClassiCube/tree/os2.

EDIT: I let the code run in IDEBUG until WinFileDlg is called. The function gets called from the main thread (i.e. main() is in the call stack). In the call stack is the window procedure reacting to a mouse button click.I suppose, this is should not be an issue, because in the end, everything gets called from the window procedure. At the time, the code is about to call WinFileDlg there is about 1M of stack memory left. This should enough, shouldn't it.
Also the dialog box flashes on the screen, and I can see a lot of dialog messages being processed, until the dialog crashes the app.

[Lars]

Another problem, I can't solve, is that the eCosoft Runtime's file dialog crash with the following code

Code: [Select]

FILEDLG fileDialog;
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) {
}
I uninstalled the runtimes. Nothing crashes, everything is fine. I reinstalled the newest runtime. The apps crashes again.
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.

[Lars]

In addition, in your latest checkin you also do this (without telling us):

fileDialog.fl = FDS_HELPBUTTON | FDS_CENTER | FDS_PRELOAD_VOLINFO | FDS_OPEN_DIALOG;
fileDialog.pfnDlgProc = WinDefFileDlgProc;

The latter is completely unnecessary as you are not providing your own file dialog window procedure anyway.

But what's more, if you use FDS_PRELOAD_VOLINFO, it is your responsibility to allocate and also manage memory for
fileDialog.papszIDriveList (read further info of how the table needs to look like in the explanation for this field).

At least that is what I would try out to check if it makes a difference.

[Jochen Schäfer]

Sure, I didn't tell you, because it's not used anymore. You quoted the code snippet, that's what I'm working with.

[Jochen Schäfer]

Another problem, I can't solve, is that the eCosoft Runtime's file dialog crash with the following code

Code: [Select]

FILEDLG fileDialog;
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) {
}
I uninstalled the runtimes. Nothing crashes, everything is fine. I reinstalled the newest runtime. The apps crashes again.
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.

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.)

[Lars]

1) Are you making sure that you are passing a fully qualified filename to fileDialog.szFullFile ?
2) is *(args->filters) the correct pointer or rather (args->filters) ? Shouldn't you copy with strcpy rather than memcpy ?


Since I have zero problems using the eCosoft runtime functions, regardless of application:

3) have you installed the latest version of the eCo Software "Win" and "Base" runtime ? I have version 2017.11.15.0 and 2018.11.8.0 installed, respectively. I think these should be the newest versions.

[TeLLie]

Hi all
Moest are from 26-01-2024
Look @ https://ecsoft2.org/eco-software-runtime

[Jochen Schäfer]

Yes, installed the newest runtimes.
szFullFile can be *.ext, and yes

Code: [Select]

*(args->filters) is correct.
strcpy vs memcpy doesn’t matter. I tried alle combinations. I also tried

Code: [Select]

char filter[CCHMAXPATJ]=„*.*“, but it doesn’t matter.

[Lars]

As Steve has already mentioned, the trap is due to a stack error.
Your app is trying to push a DWORD to mem address 0x0464fffc but the lower limit for the stack obviously is 0x04650000 (that is where ESP points to on occurence of the trap). It also does not look like your code (at least the invocation of the function in PMMERGE.DLL which is the "Win32RequestMutexSem" function I seem to remember) is being called from the main thread because TID=000a (it should be TID=0001 for the main thread).

You say that the provided stack is big enough.
The only remaining thing I can think of is that you are overwriting your stack (with EBP being overwritten with a bogus value before it is being popped or assigned to ESP). Or some recursion happens.

You will need to create a process dump and have a look at that. That should allow you to detect a recursion.