Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Ryan Johnson wrote:
> On 04/07/2012 5:45 AM, Claude SIMON wrote:
>> When I compile the component with Visual C++, it works. When I compile
>> the
>> component with g++... it crashes.
>>
>> With 'gdb', I found that the problem happens when calling the 'malloc'
>> function (as soon as the function is called, NOT when the returned
>> allocated memory is used). When I replace the 'malloc' by a the C++
>> 'new'
>> operator, the component compiled with Cygwin g++ doesn't crash anymore.
>
>> I thought that the C++ 'new' operator calls the 'malloc' function, but
>> this seems not to be the case. As I want to use 'malloc'-like functions
>> rather than the C++ 'new' operator, I wonder which functions are used in
>> the C++ 'new' operator to allocate memory (and naturally which functions
>> are used in the C++ 'delete' operator to free the memory).
> Operator new() and malloc() are explicitly *not* interchangeable (for
> many reasons, not least of which that the Standard says so). If you were
> to free new'ed memory, or delete malloc'ed memory, the resulting heap
> corruption could easily manifest as a crash the next time you tried to
> allocate something... or it might just silently clobber data and lead to
> "spooky action at a distance."
>

Thank you for the answer, but I am aware of this and my problem has
nothing to do with it, nor, as stated in the subject, with having some
lacuna in C/C++ programming.

Let's try to be a little more explicit despite my poor English.

Let's consider a Java native component which only calls a 'malloc(1)'. It
doesn't even test the returned value (it is usually not a good idea, but
it doesn't matter here).

This component :
- compiled with g++ under Linux : works,
- compiled with g++ under Mac OS : works,
- compiled with Visual C++ under Windows : works,
- compiled with g++ under Cygwin : CRASHES !

It crashes as soon the 'malloc(1)' function is called. You don't even have
the opportunity to test the returned value, nor to use it. It's perhaps a
Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't bother
(but if someone will make some investigation about that, I'm ready to help
him or her if I can).

When you replace the 'malloc()' by the 'new' operator, then the component
compiled with g++ under Cygwin works too.
The 'new' operator, among other things, allocates memory, as 'malloc()'
does, but obviously it doesn't use 'malloc()' as it doesn't crash. So,
because I can't use 'malloc()' in my Java native components, and because I
doesn't want to use the 'new' operator, I wish to know which functions the
'new' operator uses to allocate memory, so I can use them in my Java
native component so they would no more crash when compiled with g++ under
Cygwin.

-- 
Claude SIMON (sc.cygwin.com@zeusw.org)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Ryan Johnson]

On 05/07/2012 9:36 AM, Claude SIMON wrote:
> Ryan Johnson wrote:
>> On 04/07/2012 5:45 AM, Claude SIMON wrote:
>>> When I compile the component with Visual C++, it works. When I compile
>>> the
>>> component with g++... it crashes.
>>>
>>> With 'gdb', I found that the problem happens when calling the 'malloc'
>>> function (as soon as the function is called, NOT when the returned
>>> allocated memory is used). When I replace the 'malloc' by a the C++
>>> 'new'
>>> operator, the component compiled with Cygwin g++ doesn't crash anymore.
>>> I thought that the C++ 'new' operator calls the 'malloc' function, but
>>> this seems not to be the case. As I want to use 'malloc'-like functions
>>> rather than the C++ 'new' operator, I wonder which functions are used in
>>> the C++ 'new' operator to allocate memory (and naturally which functions
>>> are used in the C++ 'delete' operator to free the memory).
>> Operator new() and malloc() are explicitly *not* interchangeable (for
>> many reasons, not least of which that the Standard says so). If you were
>> to free new'ed memory, or delete malloc'ed memory, the resulting heap
>> corruption could easily manifest as a crash the next time you tried to
>> allocate something... or it might just silently clobber data and lead to
>> "spooky action at a distance."
>>
> Thank you for the answer, but I am aware of this and my problem has
> nothing to do with it, nor, as stated in the subject, with having some
> lacuna in C/C++ programming.
>
> Let's try to be a little more explicit despite my poor English.
>
> Let's consider a Java native component which only calls a 'malloc(1)'. It
> doesn't even test the returned value (it is usually not a good idea, but
> it doesn't matter here).
>
> This component :
> - compiled with g++ under Linux : works,
> - compiled with g++ under Mac OS : works,
> - compiled with Visual C++ under Windows : works,
> - compiled with g++ under Cygwin : CRASHES !
>
> It crashes as soon the 'malloc(1)' function is called. You don't even have
> the opportunity to test the returned value, nor to use it. It's perhaps a
> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't bother
> (but if someone will make some investigation about that, I'm ready to help
> him or her if I can).
>
> When you replace the 'malloc()' by the 'new' operator, then the component
> compiled with g++ under Cygwin works too.
> The 'new' operator, among other things, allocates memory, as 'malloc()'
> does, but obviously it doesn't use 'malloc()' as it doesn't crash. So,
> because I can't use 'malloc()' in my Java native components, and because I
> doesn't want to use the 'new' operator, I wish to know which functions the
> 'new' operator uses to allocate memory, so I can use them in my Java
> native component so they would no more crash when compiled with g++ under
> Cygwin.
A crash inside malloc is 99.99% likely due to a bug in user code (wild 
pointer, double-free, smashed stack, etc). The fact that your code 
doesn't crash under other circumstances does precisely *nothing* to rule 
out a bug in your code if bad has been observed anywhere (it just proves 
the platforms really are different). The buggy code may have nothing to 
do with malloc, other than having the bad luck of clobbering a data 
structure the latter needs. Even a single mix-up of new/malloc usage 
(perhaps due to losing track of a pointer's provenance) is also enough.

This is all standard memory management debugging stuff that's off topic 
for this list. If at some point you have some evidence besides "it 
crashes when I run it under cygwin" *that* would be a topic for this list.

My suggestion: run under the debugging malloc library of your choice 
and/or Valgrind and see what that turns up.

As to your question, new() usually calls malloc under the hood (with 
extra bookkeeping), but five minutes with gdb will give you a definitive 
answer.

Ryan

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[NightStrike]

On Thu, Jul 5, 2012 at 9:36 AM, Claude SIMON <sc.cygwin.com@zeusw.org> wrote:
> Let's consider a Java native component which only calls a 'malloc(1)'. It
> doesn't even test the returned value (it is usually not a good idea, but
> it doesn't matter here).
>
> This component :
> - compiled with g++ under Linux : works,
> - compiled with g++ under Mac OS : works,
> - compiled with Visual C++ under Windows : works,
> - compiled with g++ under Cygwin : CRASHES !
>
> It crashes as soon the 'malloc(1)' function is called. You don't even have
> the opportunity to test the returned value, nor to use it. It's perhaps a
> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't bother
> (but if someone will make some investigation about that, I'm ready to help
> him or her if I can).
>
> When you replace the 'malloc()' by the 'new' operator, then the component
> compiled with g++ under Cygwin works too.


Can you provide a reduced self contained small test case that
demonstrates the problem?  That'll be your fastest path to a
resolution.  It's also the easiest way to explain what you are seeing.

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Yaakov (Cygwin/X)]

On 2012-07-18 04:27, Eliot Moss wrote:
> I'll just comment that AFAIK no Java VM runs in the cygwin
> environment -- all are native Windows apps.

gcc4-java provides GIJ, and JamVM is available in Ports.


Yaakov



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Eliot Moss]

I'll just comment that AFAIK no Java VM runs in the cygwin
environment -- all are native Windows apps.  It *might* be
possible to get Jikes RVM to go under cygwin, but last I
checked a piece of linux functionality is missing, namely
the ability to look at and modify the register state saved
in the process of handling a signal.

Regards -- Eliot Moss

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Ryan Johnson wrote:
> On 13/07/2012 4:25 AM, Al Slater wrote:
>> On 12/07/2012 16:59, Claude SIMON wrote:
>>> Ryan Johnson wrote:
>>>>
>>>> [...]
>>>>
>>>> Sorry, I should have actually looked at the repo before assuming the
>>>> test case was a monstrosity. By way of penance, I've now looked,
>>>> downloaded, tweaked, and tested it.
>>>>
>>>> [...]
>>>>
>>>
>>> Thanks for testing.
>>>
>>> I removed your test results (and the other stuff) from this message,
>>> not
>>> because I'm not interested into, but because I have a new problem,
>>> which
>>> prevents me to investigate further the original problem in the light of
>>> your test results.
>>>
>>> Since my last testings, I updated Cygwin, the JDK and the JRE. So, my
>>> current configuration is now :
>>>
>>> Windows Vista 32 bits SP2
>>> Cygwin 1.7.15
>>> g++ 4.5.3
>>> javac 1.7.0_05
>>> javah 1.7.0_05
>>> java 1.7.0_05
>>>
>>> When running the test case, I now have :
>>>
>>> $ java jcmc
>>> Loading library 'jcmc'...Exception in thread "main"
>>> java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll:
>>> L'accÞs
>>> Ó cet emplacement de la mÚmoire n'est pas valide
>>>          at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>>          at java.lang.ClassLoader.loadLibrary1(Unknown Source)
>>>          at java.lang.ClassLoader.loadLibrary0(Unknown Source)
>>>          at java.lang.ClassLoader.loadLibrary(Unknown Source)
>>>          at java.lang.Runtime.loadLibrary0(Unknown Source)
>>>          at java.lang.System.loadLibrary(Unknown Source)
>>>          at jcmc.main(jcmc.java:9)
>>>
>>> There is a French message which roughly means "The access to this
>>> memory
>>> location is not valid"
>>>
>>> I updated the test case to reflect your changes :
>>>     - 'Makefile' now generates the '.h' file,
>>>     - 'Makefile' does no more contain the '--stdcall-alias' linker
>>> flag,
>>>     - the '.cpp' contains now the `extern "C"' directive,
>>>     - the '.h' is removed from test case, since it's now generated by
>>> the
>>> 'Makefiile'.
>>>
>>> I have the new error message with this modified test case, but also
>>> with
>>> the original one. I suspect that the French error message is issued by
>>> Cygwin or by one of its sub-component, since the JVM never issued a
>>> message which wasn't in English, but Cygwin did.
>>>
>>> So, I have to postpone the study of the 'malloc()' related bug until I
>>> manage to resolve this new issue ; I then come back to your test
>>> results.
>>> But, meanwhile, if someone has an idea why I have this new error...
>>>
>>> Here again the address where the test case can be found :
>>>     http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
>>>
>>
>> Does
>> http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw
>> provide any help?
>>
>
> Or, just use mingw-gcc, like I suggested before:
>> x86_64-w64-mingw32-g++ -static-libgcc -static-libstdc++ -c -g
>> -Ijdk/include -Ijdk/include/win32 "-D__int64=long long"  jcmc.cpp
>>
>> [...snip...]
>> Mingw is a windows-targeted cross compiler that runs under cygwin but
>> produces native windows binaries, so it doesn't have any posix
>> functions available; the -static flags tell mingw to make a truly
>> stand-alone executable that has only standard windows runtime
>> dependencies.
>
> Just use i686-pc-mingw32-g++ if you're 32-bit, the rest stays the same.
>

Thanks! This is what I finally, and successfully, did. I updated the test
case accordingly.

However, I would like to use the Cygwin 'default' compiler, because this
one is used more often as the 'MinGW' one and especially because I had to
do some tweaks. I had to install the 'libcgj11' package (not a big deal),
but also :
	- to copy '/usr/i686-pc-mingw32/sys-root/mingw/bin/libgcc_s_dw2-1.dll' in
'/bin'
	- in '/bin', to make a copy of 'cyggcj-11.dll' and name it 'libgcj-11.dll'.

Quite awful, isnt't it ? But without that, I didn't manage to make my
component to be loaded.

--
Claude SIMON
http://zeusw.org/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Al Slater wrote:
> On 12/07/2012 16:59, Claude SIMON wrote:
>> Ryan Johnson wrote:
>>>
>>> [...]
>>>
>>> Sorry, I should have actually looked at the repo before assuming the
>>> test case was a monstrosity. By way of penance, I've now looked,
>>> downloaded, tweaked, and tested it.
>>>
>>> [...]
>>>
>>
>> Thanks for testing.
>>
>> I removed your test results (and the other stuff) from this message, not
>> because I'm not interested into, but because I have a new problem, which
>> prevents me to investigate further the original problem in the light of
>> your test results.
>>
>> Since my last testings, I updated Cygwin, the JDK and the JRE. So, my
>> current configuration is now :
>>
>> Windows Vista 32 bits SP2
>> Cygwin 1.7.15
>> g++ 4.5.3
>> javac 1.7.0_05
>> javah 1.7.0_05
>> java 1.7.0_05
>>
>> When running the test case, I now have :
>>
>> $ java jcmc
>> Loading library 'jcmc'...Exception in thread "main"
>> java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll:
>> L'accÞs
>> Ó cet emplacement de la mÚmoire n'est pas valide
>>          at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>          at java.lang.ClassLoader.loadLibrary1(Unknown Source)
>>          at java.lang.ClassLoader.loadLibrary0(Unknown Source)
>>          at java.lang.ClassLoader.loadLibrary(Unknown Source)
>>          at java.lang.Runtime.loadLibrary0(Unknown Source)
>>          at java.lang.System.loadLibrary(Unknown Source)
>>          at jcmc.main(jcmc.java:9)
>>
>> There is a French message which roughly means "The access to this memory
>> location is not valid"
>>
>> I updated the test case to reflect your changes :
>> 	- 'Makefile' now generates the '.h' file,
>> 	- 'Makefile' does no more contain the '--stdcall-alias' linker flag,
>> 	- the '.cpp' contains now the `extern "C"' directive,
>> 	- the '.h' is removed from test case, since it's now generated by the
>> 'Makefiile'.
>>
>> I have the new error message with this modified test case, but also with
>> the original one. I suspect that the French error message is issued by
>> Cygwin or by one of its sub-component, since the JVM never issued a
>> message which wasn't in English, but Cygwin did.
>>
>> So, I have to postpone the study of the 'malloc()' related bug until I
>> manage to resolve this new issue ; I then come back to your test
>> results.
>> But, meanwhile, if someone has an idea why I have this new error...
>>
>> Here again the address where the test case can be found :
>> 	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
>>
>
> Does
> http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw
> provide any help?
>

Not really, but thanks for your suggestion.

My Java native components are usually compiled under Visual C++. As I
provide them as Free Software, I would like to provide a way to compile
this components without having to use a proprietary compiler. This is why
I went for 'Cygwin', but 'Cygwin', and especially the 'Cygwin' DLL, isn't
required for my components to work.

--
Claude SIMON
http://zeusw.org/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Csaba Raduly wrote:
> On Thu, Jul 12, 2012 at 5:59 PM, Claude SIMON  wrote:
> (snip)
>> Since my last testings, I updated Cygwin, the JDK and the JRE. So, my
>> current configuration is now :
>>
>> Windows Vista 32 bits SP2
>> Cygwin 1.7.15
>> g++ 4.5.3
>> javac 1.7.0_05
>> javah 1.7.0_05
>> java 1.7.0_05
>>
>> When running the test case, I now have :
>>
>> $ java jcmc
>> Loading library 'jcmc'...Exception in thread "main"
>> java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll:
>> L'accÞs
>> Ó cet emplacement de la mÚmoire n'est pas valide
>>         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>         at java.lang.ClassLoader.loadLibrary1(Unknown Source)
>>         at java.lang.ClassLoader.loadLibrary0(Unknown Source)
>>         at java.lang.ClassLoader.loadLibrary(Unknown Source)
>>         at java.lang.Runtime.loadLibrary0(Unknown Source)
>>         at java.lang.System.loadLibrary(Unknown Source)
>>         at jcmc.main(jcmc.java:9)
>>
>> There is a French message which roughly means "The access to this memory
>> location is not valid"
>>
>> I updated the test case to reflect your changes :
>>         - 'Makefile' now generates the '.h' file,
>>         - 'Makefile' does no more contain the '--stdcall-alias' linker
>> flag,
>>         - the '.cpp' contains now the `extern "C"' directive,
>>         - the '.h' is removed from test case, since it's now generated
>> by the 'Makefiile'.
>
> This sounds a bit like my JNI problem:
>
> http://cygwin.com/ml/cygwin/2012-07/msg00043.html
>

It's worse, as in my case, the component isn't even loaded !

You should try the 'MinGW' compiler, as I did.
With the 'default' Cygwin compiler, I never manage to have a working Java
native component. But with the 'MinGW' compiler, my Java native component
finally works !

--
Claude SIMON
http://zeusw.org/


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Ryan Johnson]

On 13/07/2012 4:25 AM, Al Slater wrote:
> On 12/07/2012 16:59, Claude SIMON wrote:
>> Ryan Johnson wrote:
>>>
>>> [...]
>>>
>>> Sorry, I should have actually looked at the repo before assuming the
>>> test case was a monstrosity. By way of penance, I've now looked,
>>> downloaded, tweaked, and tested it.
>>>
>>> [...]
>>>
>>
>> Thanks for testing.
>>
>> I removed your test results (and the other stuff) from this message, not
>> because I'm not interested into, but because I have a new problem, which
>> prevents me to investigate further the original problem in the light of
>> your test results.
>>
>> Since my last testings, I updated Cygwin, the JDK and the JRE. So, my
>> current configuration is now :
>>
>> Windows Vista 32 bits SP2
>> Cygwin 1.7.15
>> g++ 4.5.3
>> javac 1.7.0_05
>> javah 1.7.0_05
>> java 1.7.0_05
>>
>> When running the test case, I now have :
>>
>> $ java jcmc
>> Loading library 'jcmc'...Exception in thread "main"
>> java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll: 
>> L'accÞs
>> Ó cet emplacement de la mÚmoire n'est pas valide
>>          at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>>          at java.lang.ClassLoader.loadLibrary1(Unknown Source)
>>          at java.lang.ClassLoader.loadLibrary0(Unknown Source)
>>          at java.lang.ClassLoader.loadLibrary(Unknown Source)
>>          at java.lang.Runtime.loadLibrary0(Unknown Source)
>>          at java.lang.System.loadLibrary(Unknown Source)
>>          at jcmc.main(jcmc.java:9)
>>
>> There is a French message which roughly means "The access to this memory
>> location is not valid"
>>
>> I updated the test case to reflect your changes :
>>     - 'Makefile' now generates the '.h' file,
>>     - 'Makefile' does no more contain the '--stdcall-alias' linker flag,
>>     - the '.cpp' contains now the `extern "C"' directive,
>>     - the '.h' is removed from test case, since it's now generated by 
>> the
>> 'Makefiile'.
>>
>> I have the new error message with this modified test case, but also with
>> the original one. I suspect that the French error message is issued by
>> Cygwin or by one of its sub-component, since the JVM never issued a
>> message which wasn't in English, but Cygwin did.
>>
>> So, I have to postpone the study of the 'malloc()' related bug until I
>> manage to resolve this new issue ; I then come back to your test 
>> results.
>> But, meanwhile, if someone has an idea why I have this new error...
>>
>> Here again the address where the test case can be found :
>>     http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
>>
>
> Does 
> http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw 
> provide any help?
>

Or, just use mingw-gcc, like I suggested before:
> x86_64-w64-mingw32-g++ -static-libgcc -static-libstdc++ -c -g 
> -Ijdk/include -Ijdk/include/win32 "-D__int64=long long"  jcmc.cpp
>
> [...snip...]
> Mingw is a windows-targeted cross compiler that runs under cygwin but 
> produces native windows binaries, so it doesn't have any posix 
> functions available; the -static flags tell mingw to make a truly 
> stand-alone executable that has only standard windows runtime 
> dependencies. 

Just use i686-pc-mingw32-g++ if you're 32-bit, the rest stays the same.

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Al Slater]

On 12/07/2012 16:59, Claude SIMON wrote:
> Ryan Johnson wrote:
>>
>> [...]
>>
>> Sorry, I should have actually looked at the repo before assuming the
>> test case was a monstrosity. By way of penance, I've now looked,
>> downloaded, tweaked, and tested it.
>>
>> [...]
>>
>
> Thanks for testing.
>
> I removed your test results (and the other stuff) from this message, not
> because I'm not interested into, but because I have a new problem, which
> prevents me to investigate further the original problem in the light of
> your test results.
>
> Since my last testings, I updated Cygwin, the JDK and the JRE. So, my
> current configuration is now :
>
> Windows Vista 32 bits SP2
> Cygwin 1.7.15
> g++ 4.5.3
> javac 1.7.0_05
> javah 1.7.0_05
> java 1.7.0_05
>
> When running the test case, I now have :
>
> $ java jcmc
> Loading library 'jcmc'...Exception in thread "main"
> java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll: L'accÞs
> Ó cet emplacement de la mÚmoire n'est pas valide
>          at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>          at java.lang.ClassLoader.loadLibrary1(Unknown Source)
>          at java.lang.ClassLoader.loadLibrary0(Unknown Source)
>          at java.lang.ClassLoader.loadLibrary(Unknown Source)
>          at java.lang.Runtime.loadLibrary0(Unknown Source)
>          at java.lang.System.loadLibrary(Unknown Source)
>          at jcmc.main(jcmc.java:9)
>
> There is a French message which roughly means "The access to this memory
> location is not valid"
>
> I updated the test case to reflect your changes :
> 	- 'Makefile' now generates the '.h' file,
> 	- 'Makefile' does no more contain the '--stdcall-alias' linker flag,
> 	- the '.cpp' contains now the `extern "C"' directive,
> 	- the '.h' is removed from test case, since it's now generated by the
> 'Makefiile'.
>
> I have the new error message with this modified test case, but also with
> the original one. I suspect that the French error message is issued by
> Cygwin or by one of its sub-component, since the JVM never issued a
> message which wasn't in English, but Cygwin did.
>
> So, I have to postpone the study of the 'malloc()' related bug until I
> manage to resolve this new issue ; I then come back to your test results.
> But, meanwhile, if someone has an idea why I have this new error...
>
> Here again the address where the test case can be found :
> 	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
>

Does 
http://cygwin.com/faq/faq.programming.html#faq.programming.msvs-mingw 
provide any help?

-- 
Al Slater



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Csaba Raduly]

On Thu, Jul 12, 2012 at 5:59 PM, Claude SIMON  wrote:
(snip)
> Since my last testings, I updated Cygwin, the JDK and the JRE. So, my
> current configuration is now :
>
> Windows Vista 32 bits SP2
> Cygwin 1.7.15
> g++ 4.5.3
> javac 1.7.0_05
> javah 1.7.0_05
> java 1.7.0_05
>
> When running the test case, I now have :
>
> $ java jcmc
> Loading library 'jcmc'...Exception in thread "main"
> java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll: L'accÞs
> Ó cet emplacement de la mÚmoire n'est pas valide
>         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>         at java.lang.ClassLoader.loadLibrary1(Unknown Source)
>         at java.lang.ClassLoader.loadLibrary0(Unknown Source)
>         at java.lang.ClassLoader.loadLibrary(Unknown Source)
>         at java.lang.Runtime.loadLibrary0(Unknown Source)
>         at java.lang.System.loadLibrary(Unknown Source)
>         at jcmc.main(jcmc.java:9)
>
> There is a French message which roughly means "The access to this memory
> location is not valid"
>
> I updated the test case to reflect your changes :
>         - 'Makefile' now generates the '.h' file,
>         - 'Makefile' does no more contain the '--stdcall-alias' linker flag,
>         - the '.cpp' contains now the `extern "C"' directive,
>         - the '.h' is removed from test case, since it's now generated by the 'Makefiile'.

This sounds a bit like my JNI problem:

http://cygwin.com/ml/cygwin/2012-07/msg00043.html

Csaba
-- 
GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++ 5++
The Tao of math: The numbers you can count are not the real numbers.
Life is complex, with real and imaginary parts.
"Ok, it boots. Which means it must be bug-free and perfect. " -- Linus Torvalds
"People disagree with me. I just ignore them." -- Linus Torvalds

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Ryan Johnson wrote:
>
> [...]
>
> Sorry, I should have actually looked at the repo before assuming the
> test case was a monstrosity. By way of penance, I've now looked,
> downloaded, tweaked, and tested it.
>
> [...]
>

Thanks for testing.

I removed your test results (and the other stuff) from this message, not
because I'm not interested into, but because I have a new problem, which
prevents me to investigate further the original problem in the light of
your test results.

Since my last testings, I updated Cygwin, the JDK and the JRE. So, my
current configuration is now :

Windows Vista 32 bits SP2
Cygwin 1.7.15
g++ 4.5.3
javac 1.7.0_05
javah 1.7.0_05
java 1.7.0_05

When running the test case, I now have :

$ java jcmc
Loading library 'jcmc'...Exception in thread "main"
java.lang.UnsatisfiedLinkError: H:\cvs\epeios\bugs\jcmc\jcmc.dll: L'accÞs
Ó cet emplacement de la mÚmoire n'est pas valide
        at java.lang.ClassLoader$NativeLibrary.load(Native Method)
        at java.lang.ClassLoader.loadLibrary1(Unknown Source)
        at java.lang.ClassLoader.loadLibrary0(Unknown Source)
        at java.lang.ClassLoader.loadLibrary(Unknown Source)
        at java.lang.Runtime.loadLibrary0(Unknown Source)
        at java.lang.System.loadLibrary(Unknown Source)
        at jcmc.main(jcmc.java:9)

There is a French message which roughly means "The access to this memory
location is not valid"

I updated the test case to reflect your changes :
	- 'Makefile' now generates the '.h' file,
	- 'Makefile' does no more contain the '--stdcall-alias' linker flag,
	- the '.cpp' contains now the `extern "C"' directive,
	- the '.h' is removed from test case, since it's now generated by the
'Makefiile'.

I have the new error message with this modified test case, but also with
the original one. I suspect that the French error message is issued by
Cygwin or by one of its sub-component, since the JVM never issued a
message which wasn't in English, but Cygwin did.

So, I have to postpone the study of the 'malloc()' related bug until I
manage to resolve this new issue ; I then come back to your test results.
But, meanwhile, if someone has an idea why I have this new error...

Here again the address where the test case can be found :
	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios

-- 
Claude SIMON (sc.cygwin.com@zeusw.org)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Ryan Johnson]

On 12/07/2012 8:12 AM, Claude SIMON wrote:
> Ryan Johnson wrote:
>> On 10/07/2012 12:46 PM, Claude SIMON wrote:
>>> Ryan Johnson wrote:
>>>> On 05/07/2012 9:36 AM, Claude SIMON wrote:
>>>>> Ryan Johnson wrote:
>>>>>> On 04/07/2012 5:45 AM, Claude SIMON wrote:
>>>>>>> When I compile the component with Visual C++, it works. When I
>>>>>>> compile
>>>>>>> the
>>>>>>> component with g++... it crashes.
>>>>>>>
>>>>>>> With 'gdb', I found that the problem happens when calling the
>>>>>>> 'malloc'
>>>>>>> function (as soon as the function is called, NOT when the returned
>>>>>>> allocated memory is used). When I replace the 'malloc' by a the C++
>>>>>>> 'new'
>>>>>>> operator, the component compiled with Cygwin g++ doesn't crash
>>>>>>> anymore.
>>>>>>> I thought that the C++ 'new' operator calls the 'malloc' function,
>>>>>>> but
>>>>>>> this seems not to be the case. As I want to use 'malloc'-like
>>>>>>> functions
>>>>>>> rather than the C++ 'new' operator, I wonder which functions are
>>>>>>> used
>>>>>>> in
>>>>>>> the C++ 'new' operator to allocate memory (and naturally which
>>>>>>> functions
>>>>>>> are used in the C++ 'delete' operator to free the memory).
>>>>>> Operator new() and malloc() are explicitly *not* interchangeable (for
>>>>>> many reasons, not least of which that the Standard says so). If you
>>>>>> were
>>>>>> to free new'ed memory, or delete malloc'ed memory, the resulting heap
>>>>>> corruption could easily manifest as a crash the next time you tried
>>>>>> to
>>>>>> allocate something... or it might just silently clobber data and lead
>>>>>> to
>>>>>> "spooky action at a distance."
>>>>>>
>>>>> Thank you for the answer, but I am aware of this and my problem has
>>>>> nothing to do with it, nor, as stated in the subject, with having some
>>>>> lacuna in C/C++ programming.
>>>>>
>>>>> Let's try to be a little more explicit despite my poor English.
>>>>>
>>>>> Let's consider a Java native component which only calls a 'malloc(1)'.
>>>>> It
>>>>> doesn't even test the returned value (it is usually not a good idea,
>>>>> but
>>>>> it doesn't matter here).
>>>>>
>>>>> This component :
>>>>> - compiled with g++ under Linux : works,
>>>>> - compiled with g++ under Mac OS : works,
>>>>> - compiled with Visual C++ under Windows : works,
>>>>> - compiled with g++ under Cygwin : CRASHES !
>>>>>
>>>>> It crashes as soon the 'malloc(1)' function is called. You don't even
>>>>> have
>>>>> the opportunity to test the returned value, nor to use it. It's
>>>>> perhaps
>>>>> a
>>>>> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't
>>>>> bother
>>>>> (but if someone will make some investigation about that, I'm ready to
>>>>> help
>>>>> him or her if I can).
>>>>>
>>>>> When you replace the 'malloc()' by the 'new' operator, then the
>>>>> component
>>>>> compiled with g++ under Cygwin works too.
>>>>> The 'new' operator, among other things, allocates memory, as
>>>>> 'malloc()'
>>>>> does, but obviously it doesn't use 'malloc()' as it doesn't crash. So,
>>>>> because I can't use 'malloc()' in my Java native components, and
>>>>> because
>>>>> I
>>>>> doesn't want to use the 'new' operator, I wish to know which functions
>>>>> the
>>>>> 'new' operator uses to allocate memory, so I can use them in my Java
>>>>> native component so they would no more crash when compiled with g++
>>>>> under
>>>>> Cygwin.
>>>> A crash inside malloc is 99.99% likely due to a bug in user code (wild
>>>> pointer, double-free, smashed stack, etc). The fact that your code
>>>> doesn't crash under other circumstances does precisely *nothing* to
>>>> rule
>>>> out a bug in your code if bad has been observed anywhere (it just
>>>> proves
>>>> the platforms really are different). The buggy code may have nothing to
>>>> do with malloc, other than having the bad luck of clobbering a data
>>>> structure the latter needs. Even a single mix-up of new/malloc usage
>>>> (perhaps due to losing track of a pointer's provenance) is also enough.
>>> Indeed. The problem is... the crash happens even when there is no other
>>> code which could be buggy.
>> #include <stdlib.h>
>> int main() { return (int) malloc(10); }
>>
>> Does not crash. There must be some other code which is buggy.
>>
> The test case I provided is EXACTLY the code your wrote above, only
> applied to a Java native component (and without the 'return', which is not
> needed for the test case), and it DOES crash. So ?
Sorry, I should have actually looked at the repo before assuming the 
test case was a monstrosity. By way of penance, I've now looked, 
downloaded, tweaked, and tested it.

Tweaks:
- wrap the .cpp in `extern "C"' and remove the stdcall_alias linker flag 
(could have led to ABI issues)
- made jcmc.h a makefile target that calls my local javah (I'm paranoid)

My setup:
cygwin 1.7.14
jdk 1.6.0_24 (64-bit native Windows)
jre ? (32-bit native Windows)
g++ 4.7.1 (cygwin), 4.5.2 (64-bit mingw)

Attempt 1:
> $ cat jcmc.java
> class jcmc {
>         static private native void bug();
>         static public void main ( String[] args ) {
>                 System.out.print( "Loading library 'jcmc'..." );
>                 System.out.flush();
>                 System.loadLibrary("jcmc");
>                 System.out.println( " 'jcmc' library loaded !" );
>                 System.out.print( "Calling 'malloc' function from a 
> native component..." );
>                 System.out.flush();
>                 bug();
>                 System.out.println( " 'malloc' calling succeed !" );
>         }
> }
>
> $ cat jcmc.cpp
> #include "jcmc.h"
> #include <stdlib.h>
> extern "C" {
>         JNIEXPORT void JNICALL Java_jcmc_bug( JNIEnv *, jclass ) { 
> new( char[10] ); }
> }
>
> $ make
> rm -f jcmc.h jcmc.class jcmc.dll jcmc.o
> jdk/bin/javac jcmc.java
> jdk/bin/javah jcmc
> g++ -c -g -Ijdk/include -Ijdk/include/win32 "-D__int64=long long" jcmc.cpp
> g++ -shared -o jcmc.dll jcmc.o
> java -cp . jcmc
> Loading library 'jcmc'... 'jcmc' library loaded !
> Calling 'malloc' function from a native component...Exception in 
> thread "main" java.lang.UnsatisfiedLinkError: jcmc.bug()V
>         at jcmc.bug(Native Method)
>         at jcmc.main(jcmc.java:16)
This more or less was what I think you tried. I don't seg fault, but the 
malloc() function is not available at runtime. Since JNI is by 
definition not portable, and the java in my path is from some 32-bit 
JRE, I decided to try again with the JDK's 64-bit java.

Attempt 2:
> $ make
> rm -f jcmc.h jcmc.class jcmc.dll jcmc.o
> jdk/bin/javac jcmc.java
> jdk/bin/javah jcmc
> g++ -c -g -Ijdk/include -Ijdk/include/win32 "-D__int64=long long" jcmc.cpp
> g++ -shared -o jcmc.dll jcmc.o
> ./jdk/bin/java -cp . jcmc
> Loading library 'jcmc'...Exception in thread "main" 
> java.lang.UnsatisfiedLinkError: 
> C:\cygwin\home\Ryan\experiments\epeios\bugs\jcmc\jcmc.dll: Can't load 
> IA 32-bit .dll on a AMD 64-bit platform
>         at java.lang.ClassLoader$NativeLibrary.load(Native Method)
>         at java.lang.ClassLoader.loadLibrary0(ClassLoader.java:1803)
>         at java.lang.ClassLoader.loadLibrary(ClassLoader.java:1728)
>         at java.lang.Runtime.loadLibrary0(Runtime.java:823)
>         at java.lang.System.loadLibrary(System.java:1028)
>         at jcmc.main(jcmc.java:9)
>
That's clear enough... time to switch to 64-bit mingw.

Attempt 3:
> $ make
> rm -f jcmc.h jcmc.class jcmc.dll jcmc.o
> jdk/bin/javac jcmc.java
> jdk/bin/javah jcmc
> x86_64-w64-mingw32-g++ -static-libgcc -static-libstdc++ -c -g 
> -Ijdk/include -Ijdk/include/win32 "-D__int64=long long"  jcmc.cpp
> x86_64-w64-mingw32-g++ -static-libgcc -static-libstdc++  -shared -o 
> jcmc.dll jcmc.o
> ./jdk/bin/java -cp . jcmc
> Loading library 'jcmc'... 'jcmc' library loaded !
> Calling 'malloc' function from a native component... 'malloc' calling 
> succeed !
Et voilà . Don't mix 32/64 bit (if applicable), don't try to call JNI 
stuff with a different JVM than was used to create it, and life is good. 
This has nothing to do with either cygwin or new vs. malloc AFAICT. Note 
that I used new char[10] in all the examples above, so I don't know why 
you were able to run with operator new and not malloc. I don't know why 
you got a seg fault either; I assume you haven't seen such clear error 
messages as I got, or you could have solved this yourself in about five 
minutes. Maybe you have a different (older?) JVM that's less careful 
about checking runtime linker dependencies? A broken dll trampoline 
could easily cause a seg fault.

Note that cygwin has no 64-bit capabilities for the time being. Mingw is 
a windows-targeted cross compiler that runs under cygwin but produces 
native windows binaries, so it doesn't have any posix functions 
available; the -static flags tell mingw to make a truly stand-alone 
executable that has only standard windows runtime dependencies.

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Ryan Johnson wrote:
> On 10/07/2012 12:46 PM, Claude SIMON wrote:
>> Ryan Johnson wrote:
>>> On 05/07/2012 9:36 AM, Claude SIMON wrote:
>>>> Ryan Johnson wrote:
>>>>> On 04/07/2012 5:45 AM, Claude SIMON wrote:
>>>>>> When I compile the component with Visual C++, it works. When I
>>>>>> compile
>>>>>> the
>>>>>> component with g++... it crashes.
>>>>>>
>>>>>> With 'gdb', I found that the problem happens when calling the
>>>>>> 'malloc'
>>>>>> function (as soon as the function is called, NOT when the returned
>>>>>> allocated memory is used). When I replace the 'malloc' by a the C++
>>>>>> 'new'
>>>>>> operator, the component compiled with Cygwin g++ doesn't crash
>>>>>> anymore.
>>>>>> I thought that the C++ 'new' operator calls the 'malloc' function,
>>>>>> but
>>>>>> this seems not to be the case. As I want to use 'malloc'-like
>>>>>> functions
>>>>>> rather than the C++ 'new' operator, I wonder which functions are
>>>>>> used
>>>>>> in
>>>>>> the C++ 'new' operator to allocate memory (and naturally which
>>>>>> functions
>>>>>> are used in the C++ 'delete' operator to free the memory).
>>>>> Operator new() and malloc() are explicitly *not* interchangeable (for
>>>>> many reasons, not least of which that the Standard says so). If you
>>>>> were
>>>>> to free new'ed memory, or delete malloc'ed memory, the resulting heap
>>>>> corruption could easily manifest as a crash the next time you tried
>>>>> to
>>>>> allocate something... or it might just silently clobber data and lead
>>>>> to
>>>>> "spooky action at a distance."
>>>>>
>>>> Thank you for the answer, but I am aware of this and my problem has
>>>> nothing to do with it, nor, as stated in the subject, with having some
>>>> lacuna in C/C++ programming.
>>>>
>>>> Let's try to be a little more explicit despite my poor English.
>>>>
>>>> Let's consider a Java native component which only calls a 'malloc(1)'.
>>>> It
>>>> doesn't even test the returned value (it is usually not a good idea,
>>>> but
>>>> it doesn't matter here).
>>>>
>>>> This component :
>>>> - compiled with g++ under Linux : works,
>>>> - compiled with g++ under Mac OS : works,
>>>> - compiled with Visual C++ under Windows : works,
>>>> - compiled with g++ under Cygwin : CRASHES !
>>>>
>>>> It crashes as soon the 'malloc(1)' function is called. You don't even
>>>> have
>>>> the opportunity to test the returned value, nor to use it. It's
>>>> perhaps
>>>> a
>>>> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't
>>>> bother
>>>> (but if someone will make some investigation about that, I'm ready to
>>>> help
>>>> him or her if I can).
>>>>
>>>> When you replace the 'malloc()' by the 'new' operator, then the
>>>> component
>>>> compiled with g++ under Cygwin works too.
>>>> The 'new' operator, among other things, allocates memory, as
>>>> 'malloc()'
>>>> does, but obviously it doesn't use 'malloc()' as it doesn't crash. So,
>>>> because I can't use 'malloc()' in my Java native components, and
>>>> because
>>>> I
>>>> doesn't want to use the 'new' operator, I wish to know which functions
>>>> the
>>>> 'new' operator uses to allocate memory, so I can use them in my Java
>>>> native component so they would no more crash when compiled with g++
>>>> under
>>>> Cygwin.
>>> A crash inside malloc is 99.99% likely due to a bug in user code (wild
>>> pointer, double-free, smashed stack, etc). The fact that your code
>>> doesn't crash under other circumstances does precisely *nothing* to
>>> rule
>>> out a bug in your code if bad has been observed anywhere (it just
>>> proves
>>> the platforms really are different). The buggy code may have nothing to
>>> do with malloc, other than having the bad luck of clobbering a data
>>> structure the latter needs. Even a single mix-up of new/malloc usage
>>> (perhaps due to losing track of a pointer's provenance) is also enough.
>> Indeed. The problem is... the crash happens even when there is no other
>> code which could be buggy.
> #include <stdlib.h>
> int main() { return (int) malloc(10); }
>
> Does not crash. There must be some other code which is buggy.
>

The test case I provided is EXACTLY the code your wrote above, only
applied to a Java native component (and without the 'return', which is not
needed for the test case), and it DOES crash. So ?

>> As asked in another reply to this thread, I've made a test case, which
>> can
>> be found at :
>> 	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
>> There is a README file which contains some further explanations.
> If it needs to live in a CVS repo, it's not a simple test case. Those
> usually fit inline in emails (see above). Long test cases are acceptable
> if the problem can't be narrowed down further, but you'll need to make a
> substantial effort to exclude bugs in your own code before others will
> be interested to jump in. Like running a debug allocator.

As I stated in my initial post, I'm French, so perhaps I misunderstood
what you mean by a test case.
I thought that a test case is the minimal set of instructions needed to
reproduce a bug. So, since the bug occurs only in a Java native component,
I wrote a '.java' file, which loads the native component and calls the
faulty function, a '.cpp' file, which contains the source code of the
native component and implements the faulty function, and the associated
'.h' header file (actually, this one was generated by the 'javah' tool).
This 3 files represent together circa 50 lines, including the comments
generated by the 'javah' tool. I've create a dedicated directory in a CVS
repository where I put this files, so you can have a look on them only by
using your Web browser, without having to download anything. To try the
test case, you have only to download the 3 files, which is pretty simple,
I think, and additionally a 'Makefile' I wrote, which makes all the needed
compilations (after you adapt its first line). There is also a 'README'
file which explains what the content of the directory is all about.
Where am I wrong by doing this ?

>>
>>> This is all standard memory management debugging stuff that's off topic
>>> for this list. If at some point you have some evidence besides "it
>>> crashes when I run it under cygwin" *that* would be a topic for this
>>> list.
>> With the test case above, I think that it is easy to establish if the
>> problem is off or on topic.
> Great. Please do.
>

I already do this, hence the initial post.
To tell the full story, I post the initial post first on
'mingw-users@...', and I got as answer to post here. So, if someone is
kind enough to have a look on my test case, and have a suggestion where
else I should post my message, or even a solution to fix the bug, I would
be glad to know about his/her suggestion/solution.

>>
>>> My suggestion: run under the debugging malloc library of your choice
>>> and/or Valgrind and see what that turns up.
>> Should be interesting to see if a alternative 'malloc' would also crash,
>> but would not solve my problem given what I wrote above.
> Why not? Try it, you might be surprised.

If I understand well what they wrote on the 'Valgrind' Web site, it is not
available for Cygwin, nor for Windows in general. And I didn't find in the
'Cygwin' packages what tools I can use instead (I searched for 'Purify',
'Electric Fence'...)...

>>> As to your question, new() usually calls malloc under the hood (with
>>> extra bookkeeping), but five minutes with gdb will give you a
>>> definitive
>>> answer.
>>>
>> I don't manage to make 'gdb' step into a 'new' call...
> b _malloc
> r

Thanks ! But I try this, and it executes the program without stepping into
the 'new' call.

>> Beside the crash thing, all I'm interested into, is if someone here can
>> show me the implementation of the 'new' operator as used in Cygwin, or
>> give me an address where I can found the source code of this 'new'
>> implementation, or where I may ask this questions to obtain a response
>> to
>> one of this question.
> It's burned into gcc. That's why I highly doubt cygwin's code is
> directly causing the problem here.

I thought that Cygwin implements low-level memory functions, which are
used, but obviously not in the same manner, both by the 'malloc()'
functions and the 'new' operator. To verify this, I looked in the Cygwin
source repository, but I don't know enough about Cygwin and this
repository is so big that I don't know where exactly I have to go to found
the source code corresponding to the 'new' operator. So, that's why I ask
here for some help.

-- 
Claude SIMON (sc.cygwin.com@zeusw.org)




--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Ryan Johnson]

On 10/07/2012 12:46 PM, Claude SIMON wrote:
> Ryan Johnson wrote:
>> On 05/07/2012 9:36 AM, Claude SIMON wrote:
>>> Ryan Johnson wrote:
>>>> On 04/07/2012 5:45 AM, Claude SIMON wrote:
>>>>> When I compile the component with Visual C++, it works. When I compile
>>>>> the
>>>>> component with g++... it crashes.
>>>>>
>>>>> With 'gdb', I found that the problem happens when calling the 'malloc'
>>>>> function (as soon as the function is called, NOT when the returned
>>>>> allocated memory is used). When I replace the 'malloc' by a the C++
>>>>> 'new'
>>>>> operator, the component compiled with Cygwin g++ doesn't crash
>>>>> anymore.
>>>>> I thought that the C++ 'new' operator calls the 'malloc' function, but
>>>>> this seems not to be the case. As I want to use 'malloc'-like
>>>>> functions
>>>>> rather than the C++ 'new' operator, I wonder which functions are used
>>>>> in
>>>>> the C++ 'new' operator to allocate memory (and naturally which
>>>>> functions
>>>>> are used in the C++ 'delete' operator to free the memory).
>>>> Operator new() and malloc() are explicitly *not* interchangeable (for
>>>> many reasons, not least of which that the Standard says so). If you
>>>> were
>>>> to free new'ed memory, or delete malloc'ed memory, the resulting heap
>>>> corruption could easily manifest as a crash the next time you tried to
>>>> allocate something... or it might just silently clobber data and lead
>>>> to
>>>> "spooky action at a distance."
>>>>
>>> Thank you for the answer, but I am aware of this and my problem has
>>> nothing to do with it, nor, as stated in the subject, with having some
>>> lacuna in C/C++ programming.
>>>
>>> Let's try to be a little more explicit despite my poor English.
>>>
>>> Let's consider a Java native component which only calls a 'malloc(1)'.
>>> It
>>> doesn't even test the returned value (it is usually not a good idea, but
>>> it doesn't matter here).
>>>
>>> This component :
>>> - compiled with g++ under Linux : works,
>>> - compiled with g++ under Mac OS : works,
>>> - compiled with Visual C++ under Windows : works,
>>> - compiled with g++ under Cygwin : CRASHES !
>>>
>>> It crashes as soon the 'malloc(1)' function is called. You don't even
>>> have
>>> the opportunity to test the returned value, nor to use it. It's perhaps
>>> a
>>> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't
>>> bother
>>> (but if someone will make some investigation about that, I'm ready to
>>> help
>>> him or her if I can).
>>>
>>> When you replace the 'malloc()' by the 'new' operator, then the
>>> component
>>> compiled with g++ under Cygwin works too.
>>> The 'new' operator, among other things, allocates memory, as 'malloc()'
>>> does, but obviously it doesn't use 'malloc()' as it doesn't crash. So,
>>> because I can't use 'malloc()' in my Java native components, and because
>>> I
>>> doesn't want to use the 'new' operator, I wish to know which functions
>>> the
>>> 'new' operator uses to allocate memory, so I can use them in my Java
>>> native component so they would no more crash when compiled with g++
>>> under
>>> Cygwin.
>> A crash inside malloc is 99.99% likely due to a bug in user code (wild
>> pointer, double-free, smashed stack, etc). The fact that your code
>> doesn't crash under other circumstances does precisely *nothing* to rule
>> out a bug in your code if bad has been observed anywhere (it just proves
>> the platforms really are different). The buggy code may have nothing to
>> do with malloc, other than having the bad luck of clobbering a data
>> structure the latter needs. Even a single mix-up of new/malloc usage
>> (perhaps due to losing track of a pointer's provenance) is also enough.
> Indeed. The problem is... the crash happens even when there is no other
> code which could be buggy.
#include <stdlib.h>
int main() { return (int) malloc(10); }

Does not crash. There must be some other code which is buggy.

> As asked in another reply to this thread, I've made a test case, which can
> be found at :
> 	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
> There is a README file which contains some further explanations.
If it needs to live in a CVS repo, it's not a simple test case. Those 
usually fit inline in emails (see above). Long test cases are acceptable 
if the problem can't be narrowed down further, but you'll need to make a 
substantial effort to exclude bugs in your own code before others will 
be interested to jump in. Like running a debug allocator.
>
>> This is all standard memory management debugging stuff that's off topic
>> for this list. If at some point you have some evidence besides "it
>> crashes when I run it under cygwin" *that* would be a topic for this list.
> With the test case above, I think that it is easy to establish if the
> problem is off or on topic.
Great. Please do.

>
>> My suggestion: run under the debugging malloc library of your choice
>> and/or Valgrind and see what that turns up.
> Should be interesting to see if a alternative 'malloc' would also crash,
> but would not solve my problem given what I wrote above.
Why not? Try it, you might be surprised.

>> As to your question, new() usually calls malloc under the hood (with
>> extra bookkeeping), but five minutes with gdb will give you a definitive
>> answer.
>>
> I don't manage to make 'gdb' step into a 'new' call...
b _malloc
r

> Beside the crash thing, all I'm interested into, is if someone here can
> show me the implementation of the 'new' operator as used in Cygwin, or
> give me an address where I can found the source code of this 'new'
> implementation, or where I may ask this questions to obtain a response to
> one of this question.
It's burned into gcc. That's why I highly doubt cygwin's code is 
directly causing the problem here.

To be blunt, you appear to be a help vampire [1]. You haven't actually 
done any visible legwork, even the things people have taken time to 
suggest you try. I am done with this thread unless/until you do 
something to dispel that perception.

[1] http://slash7.com/2006/12/22/vampires/

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

NightStrike wrote:
> On Thu, Jul 5, 2012 at 9:36 AM, Claude SIMON <sc.cygwin.com@zeusw.org>
> wrote:
>> Let's consider a Java native component which only calls a 'malloc(1)'.
>> It
>> doesn't even test the returned value (it is usually not a good idea, but
>> it doesn't matter here).
>>
>> This component :
>> - compiled with g++ under Linux : works,
>> - compiled with g++ under Mac OS : works,
>> - compiled with Visual C++ under Windows : works,
>> - compiled with g++ under Cygwin : CRASHES !
>>
>> It crashes as soon the 'malloc(1)' function is called. You don't even
>> have
>> the opportunity to test the returned value, nor to use it. It's perhaps
>> a
>> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't
>> bother
>> (but if someone will make some investigation about that, I'm ready to
>> help
>> him or her if I can).
>>
>> When you replace the 'malloc()' by the 'new' operator, then the
>> component
>> compiled with g++ under Cygwin works too.
>
>
> Can you provide a reduced self contained small test case that
> demonstrates the problem?  That'll be your fastest path to a
> resolution.  It's also the easiest way to explain what you are seeing.
>

Thanks for your interest.
I've made a test case which can be found at :
	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
There is a 'README' file with further explanations.

--
Claude SIMON (sc.cygwin.com@zeusw.org)


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Ryan Johnson wrote:
> On 05/07/2012 9:36 AM, Claude SIMON wrote:
>> Ryan Johnson wrote:
>>> On 04/07/2012 5:45 AM, Claude SIMON wrote:
>>>> When I compile the component with Visual C++, it works. When I compile
>>>> the
>>>> component with g++... it crashes.
>>>>
>>>> With 'gdb', I found that the problem happens when calling the 'malloc'
>>>> function (as soon as the function is called, NOT when the returned
>>>> allocated memory is used). When I replace the 'malloc' by a the C++
>>>> 'new'
>>>> operator, the component compiled with Cygwin g++ doesn't crash
>>>> anymore.
>>>> I thought that the C++ 'new' operator calls the 'malloc' function, but
>>>> this seems not to be the case. As I want to use 'malloc'-like
>>>> functions
>>>> rather than the C++ 'new' operator, I wonder which functions are used
>>>> in
>>>> the C++ 'new' operator to allocate memory (and naturally which
>>>> functions
>>>> are used in the C++ 'delete' operator to free the memory).
>>> Operator new() and malloc() are explicitly *not* interchangeable (for
>>> many reasons, not least of which that the Standard says so). If you
>>> were
>>> to free new'ed memory, or delete malloc'ed memory, the resulting heap
>>> corruption could easily manifest as a crash the next time you tried to
>>> allocate something... or it might just silently clobber data and lead
>>> to
>>> "spooky action at a distance."
>>>
>> Thank you for the answer, but I am aware of this and my problem has
>> nothing to do with it, nor, as stated in the subject, with having some
>> lacuna in C/C++ programming.
>>
>> Let's try to be a little more explicit despite my poor English.
>>
>> Let's consider a Java native component which only calls a 'malloc(1)'.
>> It
>> doesn't even test the returned value (it is usually not a good idea, but
>> it doesn't matter here).
>>
>> This component :
>> - compiled with g++ under Linux : works,
>> - compiled with g++ under Mac OS : works,
>> - compiled with Visual C++ under Windows : works,
>> - compiled with g++ under Cygwin : CRASHES !
>>
>> It crashes as soon the 'malloc(1)' function is called. You don't even
>> have
>> the opportunity to test the returned value, nor to use it. It's perhaps
>> a
>> Cygwin bug, or perhaps a JVM/JRE/JDK bug ; I don't know and I don't
>> bother
>> (but if someone will make some investigation about that, I'm ready to
>> help
>> him or her if I can).
>>
>> When you replace the 'malloc()' by the 'new' operator, then the
>> component
>> compiled with g++ under Cygwin works too.
>> The 'new' operator, among other things, allocates memory, as 'malloc()'
>> does, but obviously it doesn't use 'malloc()' as it doesn't crash. So,
>> because I can't use 'malloc()' in my Java native components, and because
>> I
>> doesn't want to use the 'new' operator, I wish to know which functions
>> the
>> 'new' operator uses to allocate memory, so I can use them in my Java
>> native component so they would no more crash when compiled with g++
>> under
>> Cygwin.

> A crash inside malloc is 99.99% likely due to a bug in user code (wild
> pointer, double-free, smashed stack, etc). The fact that your code
> doesn't crash under other circumstances does precisely *nothing* to rule
> out a bug in your code if bad has been observed anywhere (it just proves
> the platforms really are different). The buggy code may have nothing to
> do with malloc, other than having the bad luck of clobbering a data
> structure the latter needs. Even a single mix-up of new/malloc usage
> (perhaps due to losing track of a pointer's provenance) is also enough.

Indeed. The problem is... the crash happens even when there is no other
code which could be buggy.
As asked in another reply to this thread, I've made a test case, which can
be found at :
	http://cvs.savannah.gnu.org/viewvc/epeios/bugs/jcmc/?root=epeios
There is a README file which contains some further explanations.

> This is all standard memory management debugging stuff that's off topic
> for this list. If at some point you have some evidence besides "it
> crashes when I run it under cygwin" *that* would be a topic for this list.

With the test case above, I think that it is easy to establish if the
problem is off or on topic.

> My suggestion: run under the debugging malloc library of your choice
> and/or Valgrind and see what that turns up.

Should be interesting to see if a alternative 'malloc' would also crash,
but would not solve my problem given what I wrote above.

> As to your question, new() usually calls malloc under the hood (with
> extra bookkeeping), but five minutes with gdb will give you a definitive
> answer.
>

I don't manage to make 'gdb' step into a 'new' call...

Beside the crash thing, all I'm interested into, is if someone here can
show me the implementation of the 'new' operator as used in Cygwin, or
give me an address where I can found the source code of this 'new'
implementation, or where I may ask this questions to obtain a response to
one of this question.

-- 
Claude SIMON (sc.cygwin.com@zeusw.org)



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Ryan Johnson]

On 04/07/2012 5:45 AM, Claude SIMON wrote:
> When I compile the component with Visual C++, it works. When I compile the
> component with g++... it crashes.
>
> With 'gdb', I found that the problem happens when calling the 'malloc'
> function (as soon as the function is called, NOT when the returned
> allocated memory is used). When I replace the 'malloc' by a the C++ 'new'
> operator, the component compiled with Cygwin g++ doesn't crash anymore.

> I thought that the C++ 'new' operator calls the 'malloc' function, but
> this seems not to be the case. As I want to use 'malloc'-like functions
> rather than the C++ 'new' operator, I wonder which functions are used in
> the C++ 'new' operator to allocate memory (and naturally which functions
> are used in the C++ 'delete' operator to free the memory).
Operator new() and malloc() are explicitly *not* interchangeable (for 
many reasons, not least of which that the Standard says so). If you were 
to free new'ed memory, or delete malloc'ed memory, the resulting heap 
corruption could easily manifest as a crash the next time you tried to 
allocate something... or it might just silently clobber data and lead to 
"spooky action at a distance."

Ryan


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Differences between C++ 'new' operator and 'malloc()' (NOT a C/C++ question)

[Claude SIMON]

Hello everybody !

I have some C++ code that I want to use in a native Java component
compiled with Cygwin g++.

I also use exactly the same C++ code in a command-line tool ('.exe' binary).

When I compile the tool with Visual C++, it works. When I compile the tool
with g++, it works.

When I compile the component with Visual C++, it works. When I compile the
component with g++... it crashes.

With 'gdb', I found that the problem happens when calling the 'malloc'
function (as soon as the function is called, NOT when the returned
allocated memory is used). When I replace the 'malloc' by a the C++ 'new'
operator, the component compiled with Cygwin g++ doesn't crash anymore.

To summarize, having some code written in C++ :
	- used in a command line tool :
		- using 'malloc' :
			- compiled with Visual C++ : works.
			- compiled with Cygwin g++ : works.
	- used in a Java native component :
		- using 'malloc' :
			- compiled with Visual C++ : works.
			- compiled with Cygwin g++ : CRASHES.
		- using the C++ 'new' operator :
			- compiled with Visual C++ : works.
			- compiled with Cygwin g++ : works.

I thought that the C++ 'new' operator calls the 'malloc' function, but
this seems not to be the case. As I want to use 'malloc'-like functions
rather than the C++ 'new' operator, I wonder which functions are used in
the C++ 'new' operator to allocate memory (and naturally which functions
are used in the C++ 'delete' operator to free the memory).

If it can be of some use, the component/tool can be found at
http://zeusw.org/intl/expp . The g++ version is 4.5.3.

Thanks !

--
Claude SIMON (sc.CYGWIN;COM@zeusw.org)
(Sorry for my poor English ; I'm French)



--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple