Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StdCallCallback fails with message of corrupted stack #300

Closed
boscogh opened this issue Jan 10, 2014 · 8 comments
Closed

StdCallCallback fails with message of corrupted stack #300

boscogh opened this issue Jan 10, 2014 · 8 comments

Comments

@boscogh
Copy link

boscogh commented Jan 10, 2014

I found out use case there StdCallCallback fails with message of corrupted stack.
It only occure with method of specific signature.
Please review my question on stackoverflow, it contains isolated testcase to 100% reproducible issue

link to the question details with source code included:
http://stackoverflow.com/questions/21039368/jna-stdcall-esp-corruption

twall added a commit that referenced this issue Jan 12, 2014
@twall
Copy link
Contributor

twall commented Jan 12, 2014

Take a look at branch issue-300 to see if you can tweak it to reproduce the error you're seeing.

@twall
Copy link
Contributor

twall commented Jan 13, 2014

9 arguments works, 11 arguments doesn't. Branch updated.

@twall
Copy link
Contributor

twall commented Jan 13, 2014

libffi may be calculating an incorrect stack size (actual 60, expected 56). This number is inserted into a dynamically generated trampoline, defined in libffi/src/x86/ffi.c.

My expectation may be off.

@twall
Copy link
Contributor

twall commented Jan 13, 2014

Updated binaries on issue-300 branch. See if it fixes your issue.

@boscogh
Copy link
Author

boscogh commented Jan 13, 2014

just tested, works perfect, thank you very much!
would it be included in some next release?
I would like to post solution in the forum of provider of that 3rd party dll.
folks tried to run it through JNA unsuccesfully since 2008 year ;-)

@twall
Copy link
Contributor

twall commented Jan 13, 2014

It’ll be included in the next release. It only affects w32-x86.

On Jan 13, 2014, at 2:57 AM, boscogh [email protected] wrote:

just tested, works perfect, thank you very much!
would it be included in some next release?
I would like to post solution in the forum of provider of that 3rd party dll.
folks tried to run it through JNA unsuccesfully since 2008 year ;-)


Reply to this email directly or view it on GitHub.

@twall
Copy link
Contributor

twall commented Jan 13, 2014

BTW, this is a bug in the underlying libffi library, so a patch will be forwarded to that project as well.

On Jan 13, 2014, at 2:57 AM, boscogh [email protected] wrote:

just tested, works perfect, thank you very much!
would it be included in some next release?
I would like to post solution in the forum of provider of that 3rd party dll.
folks tried to run it through JNA unsuccesfully since 2008 year ;-)


Reply to this email directly or view it on GitHub.

@boscogh
Copy link
Author

boscogh commented Jan 13, 2014

yes, I saw the sources of your patch and I already posted on the forum of
the 3rd party DLL (which was a part of Quik API, btw) that this was a bug
in libffi.
it is very cool to see such a fast patch, I am really glad to see such a
brilliant job!

2014/1/13 Timothy Wall [email protected]

BTW, this is a bug in the underlying libffi library, so a patch will be
forwarded to that project as well.

On Jan 13, 2014, at 2:57 AM, boscogh [email protected] wrote:

just tested, works perfect, thank you very much!
would it be included in some next release?
I would like to post solution in the forum of provider of that 3rd party
dll.
folks tried to run it through JNA unsuccesfully since 2008 year ;-)

Reply to this email directly or view it on GitHub.

Reply to this email directly or view it on GitHubhttps://github.com//issues/300#issuecomment-32165077
.

Ó Õ×ÁÖÅÎÉÅÍ,
ðÁ×ÅÌ íÁÌÀÔÉÎ

@boscogh boscogh closed this as completed Jan 13, 2014
mstyura pushed a commit to mstyura/jna that referenced this issue Sep 9, 2024
Motivation:
When Maven does not run in batch mode, it will continuously print its progress as it downloads dependencies.
This can produce a very large amount of log output, that makes it harder to debug build failures.

Modification:
- Make all Maven builds run in batch mode by adding the -B command line flag.
- Some builds were already running batch mode but had the flag in a different location – these have had their -B flag moved so all builds are consistent.
- Add -ntp flag

Result:
Much less output in our build logs where Maven is just downloading stuff.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants