I'm trying to get the LibSSH2 ssh2_exec example to work under windows but it crashes on the following line:
while ((rc = libssh2_session_handshake(session, sock)) == LIBSSH2_ERROR_EAGAIN);
The call is made ~1200 times before it crashes. What would be going wrong here?
I used this guide to compile LibSSH2 if that makes a difference.
A bit more digging suggests the crash occurs in the libssh2_sha1 function in the EVP_DigestFinal(&ctx, out, NULL); call.
I just tried a newer version of OpenSSH, built by a different source and that solved the issue.
Related
I am trying to run a previously validated C mex file on a new system. It worked correctly, with no errors, in MATLAB R2014a on Mac OS X 10.8. I am now trying to get it to run in R2015a on Mac OS X 10.10.
At first it wouldn't run because it couldn't find the MPFR library which my C code requires, so I re-installed MPFR and re-compiled the mex file with an appropriate link. The mex file compiled without any errors or warnings, but it does not run. The program doesn't throw errors either - it just hangs. I cannot ctrl-C it either, I have to force quit MATLAB.
I generally try to post more specific questions, but to be honest I have no clue as to what the problem could be here. Thanks in advance for any help.
EDIT 7-12-15 at 12:15 AM EST
This question is NOT a duplicate of the one referenced by rayryeng. My code is not crashing or generating a segmentation fault (or any error at all), unlike the referenced case. Moreover, since the code ran correctly and stably (in my own hands) on the older machine, I suspect some kind of platform- or version-dependent issue rather than bad code that needs to be debugged.
I believe this is similar to the thread: Canon SDK 2.11 on OSX
However the solution there did not work for me. I'm perplexed because I'm not sure how to figure out what has changed. I had some working software, did not work on it over the holiday and now when I open it up to work it fails. Not only my software but the demo app included with the SDK, which I have never changed and indeed used to work just fine.
I have tried with two different cameras (5DmII and 5DmIII) with the same result.
when I try and run the application, the camera is recognized but, as it attempts to open a session it receives a EXC_BAD_ACCESS signal. In each program it happens when a call is made to EdsOpenSession() with this message...
*** -[NSConcreteData release]: message sent to deallocated instance 0x8157af0
Interestingly, when I tried to use the EOS Utility that would crash also. So I updated and now that works great. I followed the suggestion in the above thread and copied the EDSDK.framework from the working bundle to my program and recompiled but I get the same results.
I'm trying to figure out how to contact Canon to get some information but they don't make it easy to get help so I'm appealing to the one group I know is responsive.
The only thing I can think is that sometime over the holiday I updated some critical library without knowing it.
Has anyone else run into and been able to solve this?
I'm running OS X 10.7.5, xcode 4.1, and EDSDK 2.11.3
Solved this. It did turn out to be the same solution as the mentioned link. However, what I was missing was that I needed to also copy the new EDSDK.framework into /Library/Frameworks not just have it in my source directory. This may be because I don't have everything setup correctly in XCode.
I am on Mac OSX 10.7 however I believe this would also appear in 10.8+
Try running (within erlang)
wx:demo().
Which will produce the following output:
beam.smp[2733:f0b] CFURLCreateWithString was passed this invalid URL string: '/System/Library/CoreServices/CommonCocoaPanels.bundle' (a file system path instead of an URL string). The URL created will not work with most file URL functions. CFURLCreateWithFileSystemPath or CFURLCreateWithFileSystemPathRelativeToBase should be used instead.
Now the demo runs just fine but why output this line then?
It speaks nothing of erlang and after some browsing around it seems as if this is a wxWidgets bug as people have the same issue in python and that it is Mac OSX centric due to the CommonCocoaPanels.bundle in the output.
Its really just an annoyance for now as everything runs just fine. But it is more than likely a bug, no?
How can it be fixed?
As far as I know wxErlang is currently broken on MacOS and maintainers promise to fix it after wxWidgets 3.0 release.
Which version of wxWidgets are you using? I used wxWidgets 2.8.12 under Mac OS 10.6.8, custom build for Carbon with -arch i386.
In wxWidgets 2.8.x, Carbon is the recommended library because it is the
more stable. Cocoa is incomplete in wxWidgets 2.8.x. If you are interested
in using Cocoa, you should start with wxWidgets 2.9.x where Cocoa is
much more complete.
The framework itself looked somehow alien to Max OS (maybe because of Carbon), a small part of API was broken (this does not prevent programs to actually run - just small annoyances).
For my future reference, and that of others..
The following will work without displaying the above error message.
P = wx:new(),
F = wxFrame:new(P, 1, "main", [{size, {600,600}]),
WindowOpts = [{size, {600,600}}, {style, ?wxSUNKEN_BORDER}],
W = wxWindow:new(F, ?wxID_ANY, WindowOpts),
wxFrame:connect(F, close_window, [{skip,true}]),
wxWindow:connect(W, paint, [{skip, true}]),
wxFrame:show(F),
wxFrame:centre(F).
Strangely enough even with all my trial and error debugging, line by line, there is really no easy way to get to the bottom of it. It turns out to be the inclusion of a:
process_flag(trap_errors, true)
Will generate that error. I am positive there is nothing crashing that would invoke the actions of the flag.
Deep error. Little consequence.
Lets hope they get it fixed along with the 3.0 upgrade.
I am trying to debug a few C++ applications with KDevelop 4.0.1(on KDE 4.4.5 and gdb 7.0.1) on Debian 6.0.6. Irrespective of what part of the code I break into, the debugger detaches automatically after stepping through a few instructions. I didn't find anything on this topic on any forums. I tried a few things below.
Debugging using gdb on shell works perfectly fine.
Tried debugging multiple applications, but the issue is seen.
Reinstalling KDevelop did not help.
Am I missing some configuration that could cause this behavior?
(I am new to kdevelop)
Thanks for any help.
My guess is that is related to pretty printing of an uninitialized variable.
Lots of fixes have been applied to KDevelop and gdb, you should consider updating to a more recent version.
first off, I really need to make a 64bit version of glfwdll.a and glfw.dll (so I can hopefully finally succeed in getting the Go glfw bindings to work under Windows ... was a breeeeze under Linux!)
Seems like I now succeeded in compiling 64bit versions of glfwdll.a and glfw.dll using mingw64, MSYS and their make scripts, even though I did get a couple of error messages along the lines of "maincrt entry point not found, using default 0xsomehexnumber instead" or some such. Entry points of course refer to executables, in this case those in the examples directory.
And indeed, most of them don't work! All got built however. The following executables work:
listmodes.exe mtbench.exe mthello.exe and particles.exe -- the latter being the only graphical (3d gfx) example working for me (the former ones just outputting some test infos onto the console window).
Now what's the issue with the other ones? They don't crash, they don't report anything to the console... I run them, they return immediately, silently.
Is my GLFW build broken? How to fix? What's the big difference between the 4 examples that work and the others that don't?
This is a fairly new, vanilla Win7 64bit installation. No crapware, everything up to date, UAC and Themes are off, not a lot of software installed at all, Nvidia GPU driver updated (GPU Caps Viewer and the likes run fine, so OpenGL is there).
I'm not yet allowed to add comments, so I'll post this as an answer.
The issue you're having is due to three separate bug in GLFW. I fixed them today and the fixes will be included in GLFW 2.7.6. Until then, you can use trunk from the GLFW Subversion repository.
To be sure that you really have no DLL-hell issues with the opengl32.dll, glu32.dll, glut32.dll etc., check out the Event Viewer tool and see if there are some warnings or errors for you app.
This is my thought because you are only able to run the mtbench and mthello which have nothing in common with the "real" OpenGL API.
No clue about particles.exe though - maybe GLFW checks for errors internally and call the exit() routine ? Check the %errorlevel% also.
Also take a look here:
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/pong3d.c?revision=1110&view=markup
There is a GameMenu() function which may exit silently if "!glfwGetWindowParam( GLFW_OPENED )", which obviously means that OpenGL was not initialized.
The same function serves as an exit flag here
http://glfw.svn.sourceforge.net/viewvc/glfw/trunk/examples/wave.c?revision=1110&view=markup
Once again, double-check the DLLs !
I believe that you are experienced not to make "advanced" mistakes in the build process, so there just might be some funny thing happening at the "user level".
And another suggestion:
http://sourceforge.net/projects/glfw/forums/forum/247562/topic/3868944
Some parameters might not work exactly for you.
To "fix" the samples try commenting out the glfwGetWindowParam call.