OS/2, eCS & ArcaOS - Technical > Communication
Zoc and Transfers
Dan Eicher:
4.15
POPUPLOG attached.
Pete:
Hi Dan
Could this be some sort of libc problem? - I ask because it seems MEGADODO.DLL is the EmTec Runtime Application DLL (User-Generated Microsoft (R) C/C++ Runtime Library) for zoc.
Are you using any libc related packages from the netlabs-exp repo? If "Yes" maybe try backlevelling to the last netlabs-rel version(s).
Regards
Pete
Dave Yeo:
--- Quote from: Pete on September 09, 2025, 06:59:11 pm ---Hi Dan
Could this be some sort of libc problem? - I ask because it seems MEGADODO.DLL is the EmTec Runtime Application DLL (User-Generated Microsoft (R) C/C++ Runtime Library) for zoc.
Are you using any libc related packages from the netlabs-exp repo? If "Yes" maybe try backlevelling to the last netlabs-rel version(s).
Regards
Pete
--- End quote ---
It won't have anything to do with the current libc as it wasn't built with GCC. You may be right about it being compiled with MS C, though that would mean 16 bit code.
Have to wait to see if Steven has any ideas as he's the expert at interpreting these type of things. Though without sym files or such, who knows.
Steven Levine:
Hi all,
This is some sort of buffer overflow which possibly corrupted the stack.
09-08-2025 15:43:36 SYS3175 PID 0059 TID 0001 Slot 007e
C:\ZOC\ZOC.EXE
c0000005
1c27b216
P1=00000001 P2=415c3a43 P3=XXXXXXXX P4=XXXXXXXX
EAX=00000000 EBX=00000001 ECX=ffffffff EDX=415c3a43
ESI=0004f404 EDI=415c3a43
DS=0053 DSACC=d0f3 DSLIM=5fffffff
ES=0053 ESACC=d0f3 ESLIM=5fffffff
FS=150b FSACC=00f3 FSLIM=00000030
GS=0000 GSACC=**** GSLIM=********
CS:EIP=005b:1c27b216 CSACC=d0df CSLIM=5fffffff
SS:ESP=0053:0004d470 SSACC=d0f3 SSLIM=5fffffff
EBP=0004d484 FLG=00010286
MEGADODO.DLL 0001:0000b216
Without looking at the megadodo.dll code, what I see in the popuplog is a typical pattern of a strlen call gone bad. ECX is the scan length and EAX is the nul character and EDI points to the string.
EDI looks like text when it should be a pointer. A bit of REXX displays
[d:\tmp]rexxtry say reverse(x2c(415c3a43))
C:\A
provides more evidence in addition to looking like that start of a path string.
Since the exception occurs after you select a file, it would appear that there's something about the selected directory or file name that is triggering the issue. ZOC is a 32-bit app and should fully support long file names, but
one never knows for sure. I would try selecting a file with a short name from a directory with a short name, as a trest.
Another possibility is the File Open Controller. If you have it enabled, I recommend disabling it or adding ZOC to the exceptions list, as a test.
FWIW, ZOC appears to be built with VAC 3.08. There's even some IBM HLL debug data in a couple of the modules.
Oddly the ORDER.EXE I have looks to be a Windows app which might be an error in the distro.
Dan Eicher:
>[d:\tmp]rexxtry say reverse(x2c(415c3a43))
C:\A
That makes sense, as I was just trying a simple test, and picking c:\autoexec.bat.
I will try disabling FOC and see if that changes anything.
I appreciate the help Steven and love tips like:
[d:\tmp]rexxtry say reverse(x2c(415c3a43))
C:\A
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version