ClassiCube porting thread

[Jochen Schäfer]

@Lars: Thank you for your persistence.
I don't why it's crashinh in a thread. CC spins of some threads for the background music and the resource HTTP fetch, but the WinFileDlg call happens in the main game loop, which runs on the main thread. IDebug tells me that, too.
I pushed the most recent changes to Github, so if somebody wants to look at the thing...
I will try to create a process dump, and post it.

[Lars]

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 that

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:

Code: [Select]

const char* const* fileExts = args->filters;
...
for (i = 0; fileExts[i]; i++)
{
if (i) String_Append(&filters, ';');
String_Format1(&filters, "*%c", fileExts[i]);
}
That might help in properly setting up the "papszITypeList" of "WinFileDlg". In fact, you should be able to do a:
fileDialog.papszITypeList = (PAPSZ)args->filters;

[Rich Walsh]

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

This is not correct. There is absolutely no indication anywhere in the *OS/2* docs that that 'fileDialog.szFullFile' is anything other than a simple string. If you wanted to filter based on multiple extensions, you do it like this: "*.exe;*.cmd" using a semicolon, not a null, to separate the filters.

Regardless, the most appropriate way to determine whether this is the source of the problem (and I doubt it is) is to make the assignment as simple as possible:  strcpy(fileDialog.szFullFile, "*.*");

see the example code for the Windows implementation

Not helpful.

[Jochen Schäfer]

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 that

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

I suspect, that thread 0a from the popuplog is spinned up by the dialog, since it's always the last one, as per process dump.

[Jochen Schäfer]

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 )

@Rich: Thanks all the same, anyone thinking about the problem could be bringing us nearer to the problem. And yes, you are correct, copying a simple string to fileDialog.szFullFile is a better solution, but I verified this already

[Jochen Schäfer]

I have attached a new executablewith my most recent version.
Can somebody with the eCoSoft runtime installed, please test it.
Please start a single player game, then press ESC. In the menu, please click on "Load Map", and then on "Load File".
If everything works, and you exit, the application will put up a crash message. I don't have investigated that.

[David McKenna]

Hi Jochen,

  I gave the new build a try and it looks a lot better than the last! Sound works too. I have the eCoSoft runtimes installed, so did as you asked and when I clicked on 'load file' a file choosing dialog briefly appears, then disappears and the game window disappears too. Get a popuplog, but no message. The initial Classicube window stays up though and can start a new game right away. Popuplog attached - thanks!

Regards,

EDIT: I added 'classicube-dev.exe' to the FOC 'do not use' list and now it doesn't crash until I hit 'Quit', then I get a message dialog saying:

Crash time: 08/05/2024 06:17:37
ClassiCube crashed.
Reason: Unhandled signal SIGSEGV (code -2147471358) at 05830000

[Lars]

Actually, there are 3 traps in Davids POPUPLOG.TXT file. And the last two trap screens seem to stem from the very same execution.

Anyway, the file tells us that now we experience traps at 2 different places in PMMERGE.DLL (I'll have to look up the second place). I think that "WinFileDlg" in isolation is not the problem but the interchange with other threads executing (like for example the thread that DIVE spins off, I seem to remember).

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.

[Lars]

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

This is not correct. There is absolutely no indication anywhere in the *OS/2* docs that that 'fileDialog.szFullFile' is anything other than a simple string. If you wanted to filter based on multiple extensions, you do it like this: "*.exe;*.cmd" using a semicolon, not a null, to separate the filters.

Regardless, the most appropriate way to determine whether this is the source of the problem (and I doubt it is) is to make the assignment as simple as possible:  strcpy(fileDialog.szFullFile, "*.*");

see the example code for the Windows implementation

Not helpful.

I talked about "fileDialog.papszITypeList" and not "fileDialog.szFullFile". Maybe you should first read what I have written before answering.
Anyways, I also doubt that that is a problem.

[David McKenna]

Hey Lars,

  I think I might have tried running ClassiCube several times, so the multiple traps in POPUPLOG may be one for each attempt. But in any case, it can be avoided by putting 'classicube-dev.exe' in the FOC 'do not use' list...

Regards,

[Jochen Schäfer]

[..]
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.

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.

One more data point, I could get, was, that when call WinFileDlg directly after WinCreateMsgQueue, the dialog stays up (without showing any files), but after that CC can't create any (p)threads, and so stops.
Something is really screwing up the memory.

FOC DNU list is less than ideal, but could be a solution.

[Lars]

[..]
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.

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.

I will need to run the DIVE samples provided with the OS/2 toolkit but I seem to remember that they are running with 3 threads where the app itself only creates 2 threads (the main thread and an additional thread for blitting). If that is true, DIVE itself seemingly is creating its own thread. And I don't know what that additional thread does and what it accesses. Looks like it is calling "WinRequestMutexSem" ...

[Lars]

Yes, DIVE seems to create an additional thread on its own.
On my system, with FOC enabled, nothing crashes. Since I seem to use an outdated version of the eCo Runtime, maybe that is the cure ?

I am still using eCS 2.2 beta. Where do you configure FOC ?

[David McKenna]

Lars,

 On ArcaOS, 'Computer'-> 'System Setup' -> 'Workplace Shell' -> FOC tab to setup FOC. Page 2 has the exception list. Don't remember if eCS has that or not...

Regards,

[Lars]

Hi Dave,

eCS does not have that "FOC" tab in the Workplace Shell Object ...

By the way: FOC has nothing to do with eCosoft Runtime.
What FOC does is to change PMCTLS.DLL to forward the entry points of these functions:
WinFileDlg
WinDefFileDlgProc
WinFreeFileDlgList

to these functions in PMEX.DLL:
WinExFileDlg (directly replacing WinFileDlg)
WinExDefFileDlgProc (directly replacing WinDefFileDlgProc)
WinExFreeFileDlgList (directly replacing WinFreeFileDlgList)

My PMEX.DLL has this size and file date:
13.04.11   9.31          13.114      0  PMEX.DLL
Unfortunately, it has no buildlevel string and I have no clue where this DLL came from or if it was part of the original eCS installation.

So, my buest guess is that PMEX.DLL has received an update with ArcaOS (apparently, as FOC now offers configuration) and that that update broke the file selection dialog functionality.
I just checked and yes, PMEX.DLL has been updated with ArcaOS.