#765 main() not called if not containing call to for example fopen()

[oinet]

I'm on Windows 7 Home Premium 32 bit, using i686-8.1.0-win32-dwarf-rt_v6-rev0. Just like tcurrent build, I had same problem with previous installed buil, a i686-7.2.0-win32-dwarf...

Below code results in NO call to main() (I have not examined whether main() is even linked in to the executable):

#include <stdio.h>
#include <windows.h> // Sleep()

int main(int argc, char **argv) {
    printf("abc"); // does nothing

    Sleep(3000); // does nothing
    return 0;
}

With below modification however, main() IS called:

#include <stdio.h>
#include <windows.h> // Sleep()

int main(int argc, char **argv) {
    FILE *file_p = fopen("<path-to-whatever-even-non-existant>", "r");

    printf("abc"); // prints "abc"

    Sleep(3000); // sleeps for 3 seconds
    return 0;
}

For your info, Digital Mars compiled executable of first example runs as expected.

[Kai Tietz]

Hello

you misinterpreted that what you saw. Of couse the main-function is
called, and linked. Otherwise the binary couldn't be linked at all.
Exisitance of main() (or equivalent) is a strict requirement for a
executable.

The issue you see is t1he stream flushing. You print something to
stdio, Then you call system sleep. Finally exiting the application.
It could be pretty helpful to know how you invoke compilation of your
little program. I would assume you are using either direct, or
indirect the gui-variant. As for this indeed stdio (along with other
standard streams) isn't connected to your console, and therefore you
don't see anything. By opening a file you indirectly initialize those
streams.
Of couse it could be something else too, but to learn more we would
need more details about how you build executable (options used), what
msvcrt you are using, what distro, etc

Kai

Am Sa., 27. Okt. 2018 um 13:50 Uhr schrieb oinet oinet@users.sourceforge.net:

---

[bugs:#765] main() not called if not containing call to for example fopen()

Status: open
Group: v1.0 (example)
Created: Sat Oct 27, 2018 11:50 AM UTC by oinet
Last Updated: Sat Oct 27, 2018 11:50 AM UTC
Owner: nobody

I'm on Windows 7 Home Premium 32 bit, using i686-8.1.0-win32-dwarf-rt_v6-rev0. Just like tcurrent build, I had same problem with previous installed buil, a i686-7.2.0-win32-dwarf...

Below code results in NO call to main() (I have not examined whether main() is even linked in to the executable):

include <stdio.h></stdio.h>

include <windows.h> // Sleep()</windows.h>

int main(int argc, char **argv) {
printf("abc"); // does nothing

Sleep(3000); // does nothing
return 0;

}

With below modification however, main() IS called:

include <stdio.h></stdio.h>

include <windows.h> // Sleep()</windows.h>

int main(int argc, char *argv) {
FILE file_p = fopen("<path-to-whatever-even-non-existant>", "r");</path-to-whatever-even-non-existant>

printf("abc"); // prints "abc"

Sleep(3000); // sleeps for 3 seconds
return 0;

}

For your info, Digital Mars compiled executable of first example runs as expected.

---

Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/mingw-w64/bugs/765/

To unsubscribe from further messages, please visit https://sourceforge.net/auth/subscriptions/

[oinet]

you misinterpreted that what you saw. Of couse the main-function is
called, and linked. Otherwise the binary couldn't be linked at all.
Exisitance of main() (or equivalent) is a strict requirement for a
executable.

A process needs to start at a certain position whose address is in the PE header. main() is then called (or jumped to) by that start routine. Anything can pontentially be happening. How would I know if linker isn't instructed to link in a "debug"/diagnostics main() that does it's own thing (whatever that may be), and then exits.

The issue you see is t1he stream flushing. You print something to
stdio, Then you call system sleep. Finally exiting the application.
It could be pretty helpful to know how you invoke compilation of your
little program. I would assume you are using either direct, or
indirect the gui-variant.

I'm using commandline: gcc -o _prog.exe main.c -Wall -Wl,--subsystem,console

As for this indeed stdio (along with other
standard streams) isn't connected to your console, and therefore you
don't see anything. By opening a file you indirectly initialize those
streams.

That's what I throught initially (regarding the problem with output function being uninitialized streams), but then I decided to also call a (to be sure) non-clib function, in this case, a Win32 function. Indeed, that function (Sleep()) didn't do anything, suggesting one of multiple things two among which could be:

1) My main() is not called, because a custom main() (or a custom startup alltogether) is linked in whose purpose is what I wrote in my first paragraph.
2) Something to do with exceptions, causing silent exit due to clib not being initialized.

Of couse it could be something else too, but to learn more we would
need more details about how you build executable (options used), what
msvcrt you are using, what distro, etc

As I wrote in my original post, I use Windows 7 Home Premium 32-bit.
About msvcrt.dll below.

--- According to Windows 7 file properties ---
File version: 7.0.7601.17744
Product version: 7.0.7601.17744

--- According to Dependency Walker ---
File version: 7.0.7601.17744
Product version: 6.1.8638.17744

A quick test (load) in x64dbg (which I'm not much familiar with). Logs from x64dbg (actually x32dbg, the 32-bit version) below after each file has "executed".

--- _prog-fopen.exe ---

Debugging: E:\Users\oinet\Desktop\c\_prog-fopen.exe
Database file: C:\__etr7priv\Applications\x64dbg\x32\db\_prog-fopen.exe.dd32
Process Started: 00400000 E:\Users\oinet\Desktop\c\_prog-fopen.exe
Breakpoint at 004014A0 (entry breakpoint) set!
DLL Loaded: 77CF0000 E:\Windows\System32\ntdll.dll
DLL Loaded: 76C00000 E:\Windows\System32\kernel32.dll
DLL Loaded: 75CE0000 E:\Windows\System32\KernelBase.dll
DLL Loaded: 76070000 E:\Windows\System32\msvcrt.dll
System breakpoint reached!
INT3 breakpoint "entry breakpoint" at <_prog-fopen.EntryPoint> (004014A0)!
Process stopped with exit code 0x0
Saving database to C:\__etr7priv\Applications\x64dbg\x32\db\_prog-fopen.exe.dd32 0ms
Debugging stopped!

--- _prog-no-fopen.exe ---

Debugging: E:\Users\oinet\Desktop\c\_prog-no-fopen.exe
Database file: C:\__etr7priv\Applications\x64dbg\x32\db\_prog-no-fopen.exe.dd32
Process Started: 00400000 E:\Users\oinet\Desktop\c\_prog-no-fopen.exe
Breakpoint at 004014A0 (entry breakpoint) set!
DLL Loaded: 77CF0000 E:\Windows\System32\ntdll.dll
Process stopped with exit code 0x0
Saving database to C:\__etr7priv\Applications\x64dbg\x32\db\_prog-no-fopen.exe.dd32 0ms
Debugging stopped!

So in the faulty executable's case, after ntdll.dll is loaded, and before kernel32.dll is loaded, process stops.

[oinet]

I just compiled the the example without fopen() in the latest (3 years old now) TDM-GCC which contains gcc/mingw-w64 version 5.1.0. The built executable runs as expected, no problem.