sh.exe has stopped working on MSW10 64bit

xpack-dev-tools / windows-build-tools-xpack

A binary distribution of the Windows Build Tools (used by Eclipse Embedded CDT)

http://xpack-dev-tools.github.io/windows-build-tools-xpack/

MIT License

191 stars 59 forks source link

sh.exe has stopped working on MSW10 64bit #9

Closed muhlpachr closed 5 years ago

muhlpachr commented 6 years ago

ilg-ul commented 6 years ago

You mean the latest version of Windows Build Tools crashes on the latest version of Win10 64-bits?

muhlpachr commented 6 years ago

Yes latest version of Windows Build Tools crashes on the latest version of Win10 64-bits but on some instances only. I am not able to distinguish why on some instances fails and on other works fine. I am now on MSW10 instance where latest BusyBox from Windows Build Tools crashes and latest BusyBox from Scoop works fine.

ilg-ul commented 6 years ago

Are you using the 64-bits of the Windows Build Tools?

muhlpachr commented 6 years ago

Yes, 64-bits of the Windows Build Tools. Behaves same as 32-bits version. But crashes are related to certain use only, in this case with make. Executing just sh.exe seams fine.

ilg-ul commented 6 years ago

Are the make files generated by Eclipse?

muhlpachr commented 6 years ago

No, ordinary make files written by hand.

ilg-ul commented 6 years ago

Hmmm... I'm afraid I'll not be able to reproduce the problem.

Any idea if BusyBox from Scoop is newer?

If so, I can try to update the Windows Build Tools to the latest BusyBox.

muhlpachr commented 6 years ago

Yes, it is hard to reproduce. I have alike issues with Scoop version of BusyBox with ls - it sometimes crashes. Scoop version is usually newer, but update to newer version will not solve root issue probably because I am having alike issues with various versions of BusyBox.

ilg-ul commented 6 years ago

BusyBox might be too light for your use case. Did you try the sh binary provided by the Git for Windows package?

muhlpachr commented 6 years ago

Well it works fine in Linux environment, so I am sure it is heavy enough ;-) There is BusyBox version od Git for Windows but it crashes more often. Heavier sh from Git for Windows has issues with paths who contain spaces unfortunately.

ilg-ul commented 6 years ago

Heavier sh from Git for Windows has issues with paths who contain spaces unfortunately.

generally make has problems with names which contain spaces, I don't know of such problems with sh.

ilg-ul commented 6 years ago

I updated the build script, it is functional now.

if you want to build your own make you can start from the current configuration.

muhlpachr commented 6 years ago

Thank you. On some MSW10 works fine, on some binaries crashes sometimes. I am not able to distinguish configuration differences unfortunately.

ilg-ul commented 6 years ago

probably your make files use some feature that requires a shell command/variable/environment/etc available only on some machines.

muhlpachr commented 6 years ago

Even if that is a case, BusyBox should not crash with unhandled exception, is not ? It should just report error message then.

ilg-ul commented 6 years ago

right, BusyBox should not crash.

but until you can reproduce the problem, I'm afraid even the BusyBox author can do little to help.

muhlpachr commented 6 years ago

Is there any chance to compile it way that faults info provide more information about nature of crash and provide leads to find root source of issue please ?

ilg-ul commented 6 years ago

The build script is functional, you can experiment with any compile options you think useful.

muhlpachr commented 6 years ago

Do you have any hints what options/debug version of libs to use to get useful info in runtime in case of crash please ?

ilg-ul commented 6 years ago

I don't have any experience with BusyBox. I would enable some debug options, to produce a detailed log.

muhlpachr commented 6 years ago

What debug options are you suggesting to catch win32 unhandled exceptions please ? I am not able to recognize any relevant one.

ilg-ul commented 6 years ago

Sorry, my experience with win32 is close to none. Check the BusyBox sources for debugging support, and possibly enable some trace.

muhlpachr commented 6 years ago

I do not understand win32 either. It seams to me there are not any win32 related code in BusyBox but it uses POSIX API emulation layer - there is root issue probably.

michael-hillmann commented 6 years ago

I can confirm the random crashes of busybox/sh.exe when using with make. My system is:

Win10 64Bit Some investigations on my side (maybe a hint, what we should investigate more intensive):
The usage in eclipse (Oxygen.3) is possible (I guess the exception is just ignored)
The usage in windows commandline (cmd.exe) like "make -f mymake.mk clean" produces the error due to the "rm" command in a valid makefile snippet: "@rm -f ./obj/*.o"
The usage of "rm -f ./obj/*.o" in windows commandline works
With VS2017 debugger, I got the windows with the exception:

michael-hillmann commented 6 years ago

Sorry, forgot to mention the version of busybox: $> BusyBox v1.28.0.git (2018-01-03 14:23:53 EST) multi-call binary

ilg-ul commented 6 years ago

Could you try the latest version too? (published a few days ago)

michael-hillmann commented 6 years ago

Ok, version $> BusyBox v1.29.0.git (2018-04-28 12:09:03 EDT) multi-call binary fixes this issue on my machine.

Thank you for your work in this very helpful project!

ilg-ul commented 6 years ago

thank you, good luck with your projects!