ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

joe_devore · Post by **joe_devore** » Mon Sep 30, 2013 7:27 pm

HI all its been a long time I hope all the Devs are in good health these days ;^_^;

I updated to the newest version of Minimalist GNU for Windows MinGW (v4.8.1)
last month or so....

I have both a copy of (v1.52), before the GUI changes (I don't use it much)
I have been using FuSoYa's 8MB fix build src to compile ZSNES these days ^_^

everything compiles fine but....
it crashes on start-up (LOL I use windows cmd files to config the compile process ^_^, plus i have a debugging area using gdb setup)...
uses multiple cmd batch files to also start debugging process... ^_^ =D oohhh yeah!
one each for the varying builds
- debug build
- release grade
- non release grade, non debugging
- and one that links to a much older version of MinGW (v3.4.2 or something I believe..)

SIGSEGV, Segmentation FAULT
zloader.c
line 942

Code: Select all

void zmain(int zargc, char *zargv[])
{

  if (init_paths(*zargv))      <<---- FAULT
  {
    #ifdef __LIBAO__
    ao_initialize();
    atexit(ao_shutdown);
    #endif
    handle_params(zargc, zargv);

    atexit(ZCleanup);
    srand(time(0));
    zstart();
  }
}

#ifdef __WIN32__
extern HINSTANCE hInst;
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
{
  hInst=hInstance;
  ImportDirectX();
  zmain(__argc, __argv);
  return(0);
}
#else
int main(int zargc, char *zargv[])
{
  zmain(zargc, zargv);
  return(0);
}
#endif

if anyone wants a copy of anything including src, cmd-batch-files, make files etc let me know..

I was wondering if any of the Devs had any ideas thx ^_^

kode54 · Post by **kode54** » Mon Sep 30, 2013 9:56 pm

Use GetCommandLine and CommandLineToArgvW and some WideCharToMultiByte magic to produce ANSI command line arguments. I don't think modern C runtime init code actually stuffs anything into __argc or __argv when starting through WinMain, so there's a null pointer dereference right there.

joe_devore · Post by **joe_devore** » Tue Oct 01, 2013 9:27 pm

kode54 wrote:I don't think modern C runtime init code actually stuffs anything into __argc or __argv when starting through WinMain, so there's a null pointer dereference right there.

ahhh......

kode54 wrote:Use GetCommandLine and CommandLineToArgvW and some WideCharToMultiByte magic to produce ANSI command line arguments.

- GetCommandLine()
- CommandLineToArgvW()
- WideCharToMultiByte()
???

wide char sounds familiar...

what would the code look like I have not used any of these specific lines of code before...?
wow a little trip to Google produced results linking to M$'s own msdn website lol
I use MAFF(Mozilla Archive File Format) to archived those pages for further reading later ^_^

___________________________________________________________________________________________________
ps:
thx for the reply Kode54, and for all your amazing Programing(bsnes, Foobar2k(pluigins, Game Music ones ^_^) loi have I left anything out =D

kode54 · Post by **kode54** » Wed Oct 02, 2013 12:37 pm

If you can't understand the APIs documented on MSDN, perhaps you shouldn't try fixing it, and wait for someone else to deal with it.

joe_devore · Post by **joe_devore** » Wed Oct 02, 2013 10:02 pm

kode54 wrote:If you can't understand the APIs documented on MSDN, perhaps you shouldn't try fixing it, and wait for someone else to deal with it.

not necessarily.... some of it makes sense maybe loi.... never actually did anything with GUI code before...

I tried this

Code: Select all

#ifdef __WIN32__
extern HINSTANCE hInst;
// int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
int  PASCAL _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPCWSTR szCmdLine, int iCmdShow)
{
  hInst=hInstance;
  ImportDirectX();
  
  // LPWSTR* CommandLineToArgvW(_In_   LPCWSTR lpCmdLine, _Out_  int *pNumArgs);
  // GetCommandLine();
  GetCommandLineW();
  CommandLineToArgvW(szCmdLine, &iCmdShow);
  
  zmain(__argc, __argv);
  return(0);
}
#else
int main(int zargc, char *zargv[])
{
  zmain(zargc, zargv);
  return(0);
}
#endif

it compiles fine but there is an error in the linking process...
the MinGW crt.. main.c:92 or ro something like that I don't have it in front of me (at the library to get on the net)

__________________________________________
ps:
I had taken in college,
- C (2001-fall-Sem, 1st year), \
- Adv. C (2002-Spring-sem),
- Data Structures in C (2002-fall-sem)(and was taking last time I was in School(college, 2nd year))

my own program I original wrote for Homework for C or was it Adv.C I don't quite remember...
but I final completed it late 2012 more or less
Console Temperature Converter ( does all three Temperatures converting 6 ways)
- 1 - Fahrenheit to Celsius.
- 2 - Celsius to Fahrenheit.
- 3 - Degrees Fahrenheit to K.
- 4 - Degrees Celsius to K.
- 5 - K to Degrees Fahrenheit.
- 6 - K to Degrees Celsius.
- 9 - Ends the program immediately.

and I ported it to C++ ^_^ that was relatively easy =D..
if you ever want a copy to check out let me know =D.
and if you would like a copy of this ZSNES src code copy let me now I will archive a copy and email it too you.

my copy includes the cmd files to compile and updated/tweaked makefiles.ms ^_^
selection of the CPU and build type(Release/debug/etc; Win32, etc)
ex:

Code: Select all

@title makeZSNES_Debug.cmd,  Compiles zsnes's Debug build
make -f makefile.ms PLATFORM=win32 RELEASEGRADE=no DEBUG=yes CPU=nocona

:: CPU OPTs
:: native, nocona
pause

joe_devore · Post by **joe_devore** » Mon Oct 07, 2013 9:56 pm

I tried this and it compiles again

Code: Select all

#ifdef __WIN32__
extern HINSTANCE hInst;
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
// int  PASCAL _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPCWSTR szCmdLine, int iCmdShow)
{
  hInst=hInstance;
  ImportDirectX();
  
  // LPWSTR* CommandLineToArgvW(_In_   LPCWSTR lpCmdLine, _Out_  int *pNumArgs);
  // GetCommandLine();
  __argv = CommandLineToArgvW(GetCommandLineW(), &iCmdShow);
  //__argc = iCmdShow;
  
  zmain(__argc, __argv);
  return(0);
}
#else
int main(int zargc, char *zargv[])
{
  zmain(zargc, zargv);
  return(0);
}
#endif

out time at the libnrary be back on 2mrw

kode54 · Post by **kode54** » Tue Oct 08, 2013 5:15 am

It may be better to do something like this:

Code: Select all

extern HINSTANCE hInst;
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
// int  PASCAL _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPCWSTR szCmdLine, int iCmdShow)
{
  typedef int (__cdecl *__getmainargs_)(int*, char***, char***, int, int*);
  __getmainargs_ __getmainargs;
  HMODULE handle;
  int argc;
  char **argv;
  char **env;
  int ret, i;

  hInst=hInstance;
  ImportDirectX();

  if ((handle = LoadLibrary("msvcrt.dll")) == NULL) return 1;
  if ((__getmainargs = (__getmainargs_)GetProcAddress(handle, "__getmainargs")) == NULL) return 1;
  i = 0;
  if (__getmainargs(&argc, &argv, &env, 1, &i) != 0) return 1;

  zmain(argc, argv);

  FreeLibrary(handle);

  return 0;
}

This is because we want ANSI arguments, not Unicode. Unicode would require significantly more effort, like adapting this stuff. Not that that's a bad idea, per se. Just using that function to produce and allocate UTF8 argv, then using the substitute functions to print UTF8 strings and open UTF8 filenames.

joe_devore · Post by **joe_devore** » Wed Oct 09, 2013 12:43 am

kode54 wrote:It may be better to do something like this:
This is because we want ANSI arguments, not Unicode. Unicode would require significantly more effort, like adapting this stuff. Not that that's a bad idea, per se. Just using that function to produce and allocate UTF8 argv, then using the substitute functions to print UTF8 strings and open UTF8 filenames.

so what I did was grab unicode arg(s) and dump them directly into __argv without converting to ansi...?? loi

I was wondering why the cmd arg were not working
I used a cmd file to load zsnes with the cmd arg "-d" which should produce a console window for internal debugging or something like that...
I got it to compile with the code I showed u above... and run... just the cmd args didn't seem to be working in the case if "-d" anyway...

I copied down the code you suggested and will give it a try at home.. thx =D

Post by **grinvader** » Wed Oct 09, 2013 5:55 pm

1.51 has no functional debugger. launching with -d is useless.

joe_devore · Post by **joe_devore** » Wed Oct 09, 2013 8:36 pm

grinvader wrote:1.51 has no functional debugger. launching with -d is useless.

loi yeah I kinda noticed the cmd flag pops up a console window but there is no cmd prompt, and donthing gets put to it..

Was it a possible future feature being developed?

kode54 wrote:It may be better to do something like this:

Code: Select all

extern HINSTANCE hInst;
int PASCAL WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, PSTR szCmdLine, int iCmdShow)
// int  PASCAL _tWinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPCWSTR szCmdLine, int iCmdShow)
{
  typedef int (__cdecl *__getmainargs_)(int*, char***, char***, int, int*);
  __getmainargs_ __getmainargs;
  HMODULE handle;
  int argc;
  char **argv;
  char **env;
  int ret, i;

  hInst=hInstance;
  ImportDirectX();

  if ((handle = LoadLibrary("msvcrt.dll")) == NULL) return 1;
  if ((__getmainargs = (__getmainargs_)GetProcAddress(handle, "__getmainargs")) == NULL) return 1;
  i = 0;
  if (__getmainargs(&argc, &argv, &env, 1, &i) != 0) return 1;

  zmain(argc, argv);

  FreeLibrary(handle);

  return 0;
}

__________________________________________________________________________________________________
ok here are the results of testing out kode54 code suggestion.

following results of testing debug build of zsnes with the new code you suggested Kode54:

- launched w/o any cmd arg(s).
-- Starts fine no errors reported to GNU Debugger(v7.6.1)...

- with "-d" cmd arg flag,
-- the following Segmentation fault occurs but....
--- Program received signal SIGSEGV, Segmentation fault.
--- 0x7c81d314 in TerminateThread () from C:\WINDOWS\system32\kernel32.dll
-- However the zsnes debugger console window has started...
-- after continuing or stepping through all the ntdll stuff below zsnes main window appears and runs just fine... loi...

Code: Select all

F:\Dev-src\2Emulators\zsnes_Testing__v1.51_(FuSoYa-8MB_R1)>
gdb -readnow --directory="F:\Dev-src\2Emulators\ZSNES_v1.51_(FuSoYa-8MB_R1)\src" 
--args "zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08).exe" -d


GNU gdb (GDB) 7.6.1

Reading symbols from 
F:\Dev-src\2Emulators\zsnes_Testing__v1.51_(FuSoYa-8MB_R1)\zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08).exe
...expanding to full symbols...done.


(gdb) r
Starting program: F:\Dev-src\2Emulators\zsnes_Testing__v1.51_(FuSoYa-8MB_R1)/zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08).exe -d
[New Thread 3248.0xdb0]

---------------------------------------------------------------------------
Program received signal SIGSEGV, Segmentation fault.
0x7c81d314 in TerminateThread () from C:\WINDOWS\system32\kernel32.dll
---------------------------------------------------------------------------

(gdb) s
Single stepping until exit from function TerminateThread, which has no line number information.

0x7c90e480 in ntdll!KiUserExceptionDispatcher () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function ntdll!KiUserExceptionDispatcher, which has no line number information.
0x7c92a824 in wcstol () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function wcstol, which has no line number information.
0x7c9033dc in ntdll!RtlCaptureContext () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function ntdll!RtlCaptureContext, which has no line number information.
0x7c92a853 in wcstol () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function wcstol, which has no line number information.
0x7c9033f8 in ntdll!RtlCaptureContext () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function ntdll!RtlCaptureContext, which has no line number information.
0x7c92a858 in wcstol () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function wcstol, which has no line number information.
0x7c901118 in ntdll!RtlTryEnterCriticalSection () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function ntdll!RtlTryEnterCriticalSection, which has no line number information.
0x7c92a97b in wcstol () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function wcstol, which has no line number information.
0x7c910339 in ntdll!RtlImageNtHeader () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function ntdll!RtlImageNtHeader, which has no line number information.
0x7c9102d9 in ntdll!RtlAllocateHeap () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function ntdll!RtlAllocateHeap, which has no line number information.
0x7c90e8cb in strchr () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function strchr, which has no line number information.
0x7c9102e5 in ntdll!RtlAllocateHeap () from C:\WINDOWS\system32\ntdll.dll

Single stepping until exit from function ntdll!RtlAllocateHeap, which has no line number information.

Post by **grinvader** » Thu Oct 10, 2013 6:22 pm

joe_devore wrote:Was it a possible future feature being developed?

It's an existing DOS port feature that will eventually be extended to be port-independent.

joe_devore · Post by **joe_devore** » Thu Oct 10, 2013 8:56 pm

grinvader wrote:It's an existing DOS port feature that will eventually be extended to be port-independent.

ahh nice... The good old DOS era days.... I remember some old games I played way back when early 1990s... Syndicate PLUS, Jill of the Jungle, Wolfenstein 3D, etc....

any idea why Kode54's code fix is generating a Segmentation Fault on the
--- Program received signal SIGSEGV, Segmentation fault.
--- 0x7c81d314 in TerminateThread () from C:\WINDOWS\system32\kernel32.dll

aside from the fact there is no actual debugger code active, because of the not ported state of the code...

on a side note last time I got svn updates it was v1.52 before the GUI change, the audio core was getting a rewrite I believe.. so the audio output wasn't working.....??

kode54 · Post by **kode54** » Mon Oct 14, 2013 10:01 am

Does it work for loading ROM images from the command line?

joe_devore · Post by **joe_devore** » Wed Oct 16, 2013 12:21 am

kode54 wrote:Does it work for loading ROM images from the command line?

ooohh ^_^ I'll try that out...
that error could be more to the point that the debugger had not been ported from the DOS code yet.

I'll check the src code to find the cmd arg to load via cmd either that or... check the web
nvm, maybe..
I found the advanced.txt..
just not sure so I'll look it over again when I get home.....

___________________________________________________
ps:
the library was closed yesterday (Columbus Day),
as far as reply eta(s)
I'll be back on 2mrw some time between
2pm and 3pm.

Post by **odditude** » Wed Oct 16, 2013 3:14 am

zsnes* romname

joe_devore · Post by **joe_devore** » Wed Oct 16, 2013 9:02 pm

odditude wrote:zsnes* romname

zsnes* romname?

is the asterisk needed?

I tested out this... this morning...
that is checking out the advanced.txt

Code: Select all

gdb -readnow --directory="F:\Dev-src\2Emulators\ZSNES_v1.51_(FuSoYa-8MB_R1)\src" --args "zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08).exe" -m ".\ROMS\Energy Breaker (J).sfc"
pause

that cmd arg works fine, ROM loads with out GUI.... hitting the [ESC] key causes ZSNES to exit normally nor errors reported to GDB.

ps:
I tried out the zsnes -? > commands.txt which did't work.... it created a blank txt file...

Post by **odditude** » Wed Oct 16, 2013 10:35 pm

joe_devore wrote:zsnes* romname?

is the asterisk needed?

no, it's a placeholder for the full executable name.

in your case, it's apparently zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08) - which is a tiny bit awkward.

joe_devore · Post by **joe_devore** » Thu Oct 17, 2013 12:15 am

odditude wrote:
joe_devore wrote:zsnes* romname?

is the asterisk needed?
no, it's a placeholder for the full executable name.

in your case, it's apparently zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08) - which is a tiny bit awkward.

I have setup for my both the v1.51 and the v1.52 src folders... testing folders...

G:\Dev-src\2Emulators\zsnes_Testing__v1.51_(FuSoYa-8MB_R1)
G:\Dev-src\2Emulators\zsnes_Testing__v1.51_(FuSoYa-8MB_R1)\roms
zsnesw_v1.51_(+nocona-opt2_mmx&sse2)+(2013-08-17).exe <<-- Non-Release-grade and non-debug, default?
zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08).exe
zsnesw_v1.51_ReleaseGrade_(+nocona-opt2_mmx&sse2)+(2013-08-17).exe
zsnesw_v1.51_ReleaseGrade_(+nocona-opt2_mmx&sse2)+(2013-08-17)_old-gcc.exe <<-- built with a backup of and older version of MinGW during the Dev-C++ days...

the name includes the build type(release or debug), CPU-opt, ext-opts, and the compile date...
becuase I have saved older compiles for testing...
and I use cmd bat files to run gdb debugger

G:\Dev-src\2Emulators\zsnes_Testing__v1.52
G:\Dev-src\2Emulators\zsnes_Testing__v1.52\roms

__________________
edit
I just tried out loading rom name including..

Code: Select all

gdb -readnow --directory="F:\Dev-src\2Emulators\ZSNES_v1.51_(FuSoYa-8MB_R1)\src" --args "zsnesw_v1.51_Debug_(+nocona-opt_mmx&sse2)+(2013-10-08).exe" ".\ROMS\Energy Breaker (J).sfc"
pause

Loads ROM directly.. GUI opens with [ESC] key like usual...
no errors detected in GNU Debugger (gdb)

joe_devore · Post by **joe_devore** » Fri Oct 18, 2013 9:25 pm

update:
ps: I have updates for an old Chrono Trigger glitch thread
Chrono Trigger: reoccuring gfx bug (intro)

in short, when compiling zsnesw.exe from source-code ..
setting ASM optimizations to 0 int the makefile:
ASMOPT=-O0

stopped the reoccurring Chrono Trigger - Intro glitch ~ Black Omen scene glitch.. loi

Post by **grinvader** » Sat Oct 19, 2013 12:59 pm

Don't worry about that stuff.

joe_devore · Post by **joe_devore** » Sat Oct 19, 2013 9:39 pm

grinvader wrote:Don't worry about that stuff.

? what do you mean? I thought it was pretty interesting that a particular glitch wasn't occurring under certain compiling conditions... loi

Post by **grinvader** » Sun Oct 20, 2013 8:10 am

Interesting enough to spam it thrice on the same board ?

Anyway that's moot.

joe_devore · Post by **joe_devore** » Mon Oct 21, 2013 7:47 pm

grinvader wrote:Interesting enough to spam it thrice on the same board ?

Anyway that's moot.

ahh sorry it wasn't meant to be anything like spamming ;_;

....

It was meant to leave a linked reference to the other thread... since it was related to my compiling with the latest MinGW... and in case some one saw/read this topic but missed the other one...

ZSNES board

ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)

Re: ZSNES(v1.51) startup crash compiled on MinGW (v4.8.1)