`lldb::SBDebugger::Initialize();
lldb::SBListener sbListener;
lldb::SBTarget sbTarget;
lldb::SBError sbError;
sbTarget.ConnectRemote(sbListener, "connect://127.0.0.1:3333", nullptr, sbError);
if (sbError.IsValid()) {
printf("%s\n", sbError.GetCString());
//got an error "SBTarget is invalid"
}`
xcode 11.6 connect ios13.3.1 got an error "SBTarget is invalid"
how to use lldb sbapi in xcode
This isn't a supported use of lldb within Xcode.
Xcode knows nothing about new debuggers you make by hand, and since Xcode is the one that hooks debuggers up to the Console window, it wouldn't know to provide you a way to interact with them.
Also, lldb is an event-driven framework, but your new target is hooked up to an event listener that Xcode knows nothing about, so it won't know the drive its event loop.
Even if you did manage to get one of the debuggers in Xcode to wait for your new target's events, Xcode expects one target per debugger, so if you caused events for a second target to show up, Xcode would just get confused.
I think what you really want to do is to customize the startup sequence (essentially script the action of the Run part of Xcode's Build & Run button). That is a perfectly reasonable enhancement request. If you are so motivated, feel free to file a bug report. These days it looks like you use the Feedback Assistant app for that purpose. See:
https://developer.apple.com/bug-reporting/
But I don't think you are going to have much luck doing this without cooperation from Xcode.
Related
I would like to make a Graphical interface for a home-made program using SFML on Raspberry Pi2. I am using Raspbian. I recompiled the graphical lib
It works fine unsing startx first, then using my application, which wors perfectly fine.
But I can't figure if it is possible or how to launch my application directly after boot without launching startx (just to optimise the cpu of the Raspberry).
Starting my program direcly after boot, I get the following error:
Failed to open X11 display: make sure the DISPLAY environnement variable is set correctly.
Aborted.
I already tested the classic export DISPLAY=:0.0 but without sucess.
I interested myself in x and xinit, but I am not sure that would even do it.
Where should I start looking? I don't need a complete solution, even a hint or an idea would be nice!
I checked to see if it was possible to open a graphical app without the X desktop environment and as that answer states, with Firefox at least, you need the X server which SFML also probably needs in order to create a window.
The answer states:
Basically something like:
$ X
Then you just start Firefox in this X server:
$ DISPLAY=:0 firefox
You can switch from the X server and the framebuffer by using
CTRL+ALT+F1 and CTRL+ALT+F7.
You could try that and see if it helps.
Also, still searching, I found a forum post on the sfml website about what you're trying to accomplish stating somewhere:
SFML requires OpenGL, so as far as I know you need at least X running,
but you probably don't need gnome, KDE or a similar Desktop
Environment on top.
The forum guy asking for help seems to have managed to get X11 and a SFML basic render window to work on Ubuntu server after someone posted a link to xinitrc. I guess, that's the route to go from here.
I'm a rookie at C in general and VS 2013 also. I am trying to use some C code provided by a vendor in VS 2013 express. It compiles and runs without problem using the command line compiler but I would like to use the IDE.
I started a new project, C++ for console app, and I have pasted the code into the IDE and saved it as xyy.c so that it builds successfully. I thought it would be nice to have it in a GUI, so I duplicated the effort with a Win32 app project. It also builds.
The program's job is to connect to a PCI card that has Plx chip as an interface and program an FPGA. The Win32 program succeeds, even though I can't see any of the info printed by the program. The console program fails and I think it is because it fails to find the driver for the Plx chip. I thought I would get a clue by single stepping through the Win32 program to see which driver was supposed to be found.
However, after the first pass through a while loop, I get a pop up that says "Source Not Found" and "stack.cpp not found". Google wasn't any help to me.
I be grateful for any suggestions.
You might have "Enable .NET Framework source stepping" enabled (see http://msdn.microsoft.com/en-us/library/cc667410.aspx). So when you are at Stack... and trying to step into, it will actually try, but you don't have the sources for that. There is also a new experience for using the .NET framework reference source that was announced recently: http://blogs.msdn.com/b/dotnet/archive/2014/02/24/a-new-look-for-net-reference-source.aspx
I faced the same problem. I advise at the moment of receiving the information "stack.cpp not found" to look at the stack trace and check if there is something like this: "RTC".
If there is, you need to change the flag along the path (for example, set the Default or a more convenient configuration for you):
Project Properties -> C/C++ -> Code Generation -> Basic Runtime Checks
More details: https://learn.microsoft.com/en-us/cpp/build/reference/rtc-run-time-error-checks?view=msvc-160
When I launch my WPF application and when it goes to InitializeComponent function call of one user control, it silently quits and only leaves one message in the output window saying Managed (v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's how I normally find where the problem is)
Here is what I did: in this application project we need to use a reference Microsoft.Office.Interop.Owc.dll, with version number 10.0.4504.0. Since it is an interop library, when I added this reference in VS2012, it automatically sets the property Embedded Interop Types as true, which I assume means it will not keep an individual dll in the output folder but instead embed this library into the main output (at least this is how it seems in our other references, for example, Microsoft.Office.Interop.Outlook.dll). However, when I launch the project, it throws an XamlParseException saying:
"Could not load file or assembly 'Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system
cannot find the file specified.":"Microsoft.Office.Interop.Owc, Version=10.0.4504.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35""
It seems that the reference was not embedded(or the version is not currect. But I verified that the reference version is indeed 10.0.4504.0)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this library. This time the exception is not thrown, but the whole application just silently quits as I described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no article about it. I tried to set the Embedded Interop Types to true/false but the problem is the same.
UPDATE:
I'd like to add more description here. As mentioned above, the problematic library is OWC(Office Web Component)10. I followed this link to make OWC work with VB.NET desktop application: HOW TO: Handle Events for the Office Web Components in Visual Studio .NET. But this official article is so old so I had to make a lot of changes to compile the wrapper dll(mainly because of namespace mismatch). Then when I add the reference to the actual interop library Microsoft.Office.Interop.Owc, if I follow the default setting and let the Embedded Interop Types as True, at runtime it will complain (throw a XamlParseException) that the assembly cannot be loaded (see description above). What the hell? I thought make it as "embedded" would guarantee this library will be found. Then I copy this dll to the output folder, then I have this silently quit problem. But it might be worth mentioning that this time the output window shows the Microsoft.Office.Interop.Owc.dll is indeed loaded. Actually it is the last message before the managed has exited message. So it must still relate to this library.
All of this only happens with OWC10. There is actually a similar way to do that in OWC11(the latest, but unfortunately still pretty old version since it came with Office2003): HOW TO: Handle Events for the Office 2003 Web Components in Visual Studio .NET. But it actually works and the control is displayed on my application. It is because of some other reason that I wanted to try OWC10 instead of OWC11
When I launch my WPF application and when it goes to InitializeComponent function call of one user >control, it silently quits and only leaves one message in the output window saying Managed
(v4.0.30319)' has exited with code -1073740771 (0xc000041d). When I say "silently", I mean there is >no exception is caught even if I wrap this InitializeComponent call with a try-catch block (that's >how I normally find where the problem is)
Next I copied this dll directly to the output folder bin\Debug\, to make sure that it can find this >library. This time the exception is not thrown, but the whole application just silently quits as I >described in the beginning. I tried to google the code -1073740771 (0xc000041d) but there is no >article about it. I tried to set the Embedded Interop Types to true/false but the problem is the >same.
I had exactly the same thing happening to me today, "has exited with code -1073740771 (0xc000041d)." (This happened in both a VB and C# .NET WinForms application for me). I tried debugging and saw I never even got into the Form_Load code block.
I "solved" this in the end by running visual studio as an administrator (and then just opening & building and running the project via the menu).
This is a win8 security issue and it isn't well explained anywhere.
(I got distracted and just opened up a specific project straight out of my task bar/solution file which caused this to happen to me).
You've probably found this out by yourself by now, hope you didn't lose any hair over it :)
Just pointing this out for other people who might have this error occuring somewhere.
Also had this issue, the 'silent' exit with code -1073740771 (0xc000041d) on x64 platforms, on x86 platforms everything was OK.
Part of my application is unmanaged C++, another part is C#. It turned out that my C++ code was not completely ready for the x64 platform. The following change fixed the issue in my case:
// before
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG>(WindowProc)));
// fixed version
g_OrigWndProc = reinterpret_cast<WNDPROC>(::SetWindowLongPtr(hWnd, GWLP_WNDPROC,
reinterpret_cast<LONG_PTR>(WindowProc)));
So, the generic recommendation is to verify that your code is completely ready for the x64 platform.
I've got a strange problem I haven't seen before. I can open an OpenFileDialog in Windows 7 without any problems. However, when I try my app on Windows XP, calling OpenFileDialog.ShowDialog() immediately crashes the application. It just vanishes! When running from the debugger, I don't get any unhandled exceptions. If I wrap the code in a try/catch block, nothing gets caught. I have also checked all thrown exceptions in Debug -> Exceptions, but nothing pops up. I'll try some of the other suggestions in the answers below and will report back.
Does anyone know how to resolve this problem? I found a post about something similar, but it was the opposite problem. I'll try tweaking the desktop settings to see if it's related to that, but I am dubious.
EDIT -- as a sanity check, I wrote a test WPF application that displays an OpenFileDialog directly via the main window as well as another Window that can be displayed by the main window. It totally works fine under Windows XP. So now I'm really confused. I have verified that I'm not doing something stupid like trying to display the dialog from a worker thread. The OpenFileDialog displays briefly, then disappears along with the application.
EDIT -- I'm going to try to reproduce this problem on another XP computer. For now, I'll try Windows XP mode and we'll see what happens.
I got a similar error when a DLL crashes when I open a OpenFileDialog. It turned out that OpenFileDialog changed the working directory so my dll tried to write to a relative file that did not exist.
Do you see any "First Chance" exceptions in the Output? Any entries in the event log? Does the default path you're using exist on the XP machine?
Try adding a handler to the App Domain's UnhandledException
Does the same happen when you use a brand new, stock FileOpenDialog without any tweaks? What about from a brand new app which does nothing but show a file open dialog?
See Galet's post
I cannot tell you what exactly the problem is, but here's what you could do to get a clue what's really happening. I assume you're using VS2008 or 2005.
1.Switch to release mode
2.Go to Debug\Exceptions, and mark all "Thrown" exceptions, like illustrated here: http://vvcap.net/db/JbWS_tzy2IpBoI7R7amm.htp
3.Run executable in debugger, ignore the warnings from VS that there's no debug info
It does seem that there's a win32 exception thrown some time during execution, but this way or another, you will get one or more messages from debugger explaining what kind of exception happened and where. In most cases those messages make it pretty clear what exactly went wrong
EDIT: One thing I forgot to mention is that unmanaged debugging must also be turned on, such like here (when you start program directly from IDE) or here (when you attach to running process)
link|edit|flag edited Apr 12 '09 at 22:32
answered Apr 10 '09 at 19:01
galets
1,2201924
I have an application that uses LoadLibrary on Windows to dynamically load plugins. However some of the plugins have other dependent DLLs, such as database client DLLs.
When you attempt to load such a DLL and one of the dependent DLLs doesn't exist you get a nasty Windows dialog:
"The program can't start because xxx.ddl is missing from your computer. Try reinstalling the program to fix this problem."
Is there any easy way to avoid this dialog? I was hoping one could use LoadLibraryEx and pass a flag that says "don't give me that annoying dialog", but it doesn't seem like it.
What I'd like is for the application to handle that error, rather than Windows handling it for me, especially as the text of the message is incorrect (the problem isn't that the program can't start, the program is running quite happily, it just can't load this plugin).
What I'd like to avoid is having to rewrite the plugins that have these external dependencies to make them themselves do a dynamic load of any dependent modules and then query for any entry points.
Anyway, any suggestions would be gratefully received.
Use SetErrorMode(). Use it with SEM_NOOPENFILEERRORBOX | SEM_FAILCRITICALERRORS before you load the DLL and with 0 right after.
From MSDN:
To enable or disable error messages displayed by the loader during DLL loads, use the SetErrorMode function.
Link here