Would it be possible to execute QtCreator as a nornal user but run and debug an application as root?
That would be useful i.e. while developing applications based on WiringPi, which facilitates the access to GPIO but requires root to effectively enable access to the hardware.
To be more clear in my intentions, I would like that when I hit Ctrl+R in QtCretor, then it runs the app as root. And the same idea for debugging, when I hit F5 it starts debugging mode as root. All that while QtCreator is running by a normal user.
WiringPi does not need root access. You need to set properties to the relevant device nodes properly, that's all. Make sure you have /dev/gpiomem available for use by WiringPi, writable by the user. It's available on 4.1 and newer kernels IIRC.
Your question is a case of an X-Y problem. Yes, root access sidesteps the problem of wrong device node properties, but it's not a proper solution at all. Don't run your application as root.
I solved today the same issue with wiringPi following this comment: https://askubuntu.com/a/711130
In my case it was:
Tools-> Options-> Environment replaced the default string with "/usr/bin/xterm -e sudo" in terminal option.
Also, do not forget to go to Projects > Build & Run > Run and check the box Run in terminal.
The short answer is no. Even if you could start the application to run as root from within a non-root QtCreator context, you would not be able to connect to the running process and debug it.
You are better off just running QtCreator as root.
If you need to develop a "user mode" interface to the GPIO pins, you can try
this tutorial: LED Driver
It shows a way to create nodes within the /sys tree that can give you usermode access to the GPIO.
Related
In the past (10.11 to 10.14), to debug a System Pref Pane, you could make a copy of System Preferences and self-sign it, then use this copy as the debug target. This method bypassed the System Integrity Protection restrictions.
With Catalina, all third party prefPanes are now loaded in a system process called "legacyLoader". This is located at:
/System/Library/Frameworks/PreferencePanes.framework/Versions/A/XPCServices/legacyLoader.xpc/Contents/MacOS/legacyLoader
Self-signing a copy of legacyLoader is no longer possible. Although you can obviously still make a copy and self-sign it, there is no way to force System Preferences to use the modified self-signed copy as it will always launch the built-in, Apple-signed legacyLoader.
The only way I can see on 10.15 to debug a prefPane is to disable SIP system-wide. Not a great solution.
Does anyone know a way to debug something in legacyLoader without disabling SIP?
I have tried creating my own host application to load the prefPane during development but I have run into a few bugs that only show up when running in System Preferences (legacyLoader) that do not show up when running in my own host.
I really need a way to debug these in the real environment without the inherent security risks of disabling SIP.
I want to setup the following environment: I've got a STM32H753I-EVAL2 eval board, connected on a Windows PC. Until now I was developping and debugging locally on this PC with STM32CubeIDE. For several reasons my code source is on a Linux server (Samba mounting) so it takes forever to build a project. Hence I want to develop on the linux server from my Windows machine.
Compiling is working fine (and is way faster) but the issue is about debugging. I know it is possible to debug remotely, the Debug Configuration window from Eclipse (I'm using OpenOcd) allows to connect to a remote GDB server. What I don't know is how to start a GDB server on the Windows machine that will connect to the STM32 board ?
Sorry for the "answer to myself" but I think it might be useful for others (and even to me when I have forgotten in a few weeks ;) ).
Here is how to do.
on host side (on the machine where the eval board is physically plugged in) you have to manually launch the GDB server application that comes with STM32CubeIDE installation. See STMicro application note UM2576 for details. The default command line is:
ST-LINK_gdbserver.exe -d -v -cp "C:\ST\STM32CubeIDE_1.0.0.19w12patch\STM32CubeIDE\plugins\com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.win32_1.0.0.201903011553\tools\bin"
Now you've done the hardest. On server/remote side you have to setup the Debug Configuration to use OpenOcd with option "Connect to remote GDB server" and simply enter IP address and port number (which is not 3333 by default but 61234, but it can be modified).
This setup is working fine, even if I encoutered some instabilities during debugging once in a while.
I see two (maybe three) options
Use an alternate GDB server (see below)
Run the GDB server from STMCubeIDE in isolation (see OP's answer for Windows, this answer for Linux)
GDB Serial (not really an option right now but I'll share my experience so far)
I have used the second option to succesfully debug my target using arbitary GDBs such as gdb-multiarch command line and in the (non STMCube-ified) Eclipse CDT
Alternative GDB Servers
You could try STLink open source. I did. The problem is, your device might not be supported properly. I built 1.6.1 from Github to enable support for STM32G03x device. While moving to this version enabled it to detect the device, and I can use st-flash to program the device, the debugger is unusable (try and alter a register, it alters the wrong one, try and single step a program, it crashes immediately).
Do try it though .. it's easy and quick to install (or build), so it's worth checking if your device will work correctly with it.
Openocd is another option, but seems not to support SWD connection. I tried a build that allegedly had a patch for this but no luck.
If you can get one of these open source alternatives to work, they have another advantage, you may be able run them on something like a Raspberry PI, which means you don't have to get a PC physically close to your target.
Run the GDB server from STMCubeIDE in isolation
For Windows, see the OP's answer. For Linux, I do this alter the pathnames to suit your installation
LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/native/linux_x64/ /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.stlink-gdb-server.linux64_1.5.0.202011040924/tools/bin/ST-LINK_gdbserver -p 61234 -l 1 -d -s -cp /home/user/apps/st/stm32cubeide_1.5.1/plugins/com.st.stm32cube.ide.mcu.externaltools.cubeprogrammer.linux64_1.5.0.202011040924/tools/bin -m 0 -k
How did I get to this? Firstly launched a debugging session from STMCubeIDE, then ran
ps aux | grep gdbserver
Then we can see how Eclipse (STMCube) is launching the gdbserver and work from there.
If you find it complains about a .so file, locate that file from the STMCube installation and ensure the path to the directory containing it is in LD_LIBRARY_PATH (as per my example)
You can also launch the program with --help to show more options.
If add -e (persistent) you can disconnect and reconnect a GDB client without resetting the target (it will reset on initial invocation of the gdb server though, even without -k).
GDB Serial
This is where the target implements the GDB server end of the protocol. The GDB stub usually runs in an exception handler. This would usually be your breakpoint handler but you can also make it the default handler for unhandled exceptions, or, for example, the ctrl-c interrupt.
I have done a lot of Googling about this recently and basically when people ask about it on forums they usually get responses along the lines of "Here be dragons" or "Why don't you use JTAG?"
So the drivers for this, you might like to know, are in the GDB sources git://sourceware.org/git/binutils-gdb.git under gdb/stubs. The documentation is here. There isn't a stub implementation there for arm. Which is sad really, I used to use GDB remote serial regularly where I worked, and some of those targets were indeed ARM. The operating system was ecos.
So could ecos GDB stubs be ported to bare metal? Having giving it a good coat of looking at, I believe yes they could. The stubs are based on the ones from the GDB sources but they are heavily polluted with Ecos and Redboot build macros and copyright (the ogiringals were written by HP and released without copyright). We don't know what bugs the Ecos stubs may contain (I fixed at least one back in the day and I don't recall whether I submitted a patch). We don't know if they really support the latests architectures properly. And, we don't know if, after that, they simply use up too much memory - my STM32 has 8K of SRAM and I already see buffers that have a default size of 2K (not saying that's necessary but you see how work needs to be done here..)
So this third option, I will revisit this one day but for now, for me, it's a nope.
I have wrote a program which tries to write a file in C:\windows\ directory. I have tested the program in several PCs with winXP, win7 (64 & 32 bit).But when i install it in my client's PC it crashed with the message : TODO ( file description ) has stopped working
Please if anybudy knows any solution then reply me.
The solution is not to write to the C:\Windows folder. You're not working for the Microsoft Windows team.
It is quite awesome that you gave your client a "TODO:..." product? Please edit the version info to reflect your product name~
As for crash scenario:
Check if your application really needs Admin rights, if yes, start with "run as admin" and see it it solves the problem.
View the problem details in either "Stopped working dialog box", or in Windows event viewer. In both, you can see the exception code (like 0xC0000005) and the DLL name. For this you should enable PDB file generation by enabling /DEBUG flag in linker setting (this is not same as _DEBUG macro in compiler settings!).
Put some file-logging or message-boxing (temporary) and see till where program goes properly. Yes, you need to make few changes, build and give again to your client (and please no "TODO" as product name - be professional!).
There are a few possible causes, among them no write access(perhaps the user running the program does not have write access to C:\Windows folder. Try to manually create a file in that location.) or faulty programming.
In any case, you have a few things to try to figure out the problem. If debug is impossible you should put the sensible parts of the code in try catch blocks (for example the part where you write the file). And if error is caught you can output a message about the part where the error is. You should also include a logging solution and add logs in various places of the code. After you install the updated application, when you get an error, look up in the log file to see where the code stopped.
Is it possible you have UAC turned off, but your client doesn't? Or, would the client's user not have administrative rights? A user process would not be allowed to write to the c:\Windows folder. If that's the case, trying to create a file would throw an exception.
The proper place to create a data file would be:
Application Data under the user's folder, if the file is per user.
ProgramData (Win7) or Application Data under All Users (XP), if the file is per application (log or so).
Apart from the issue of permissions the first thing that will cause your application to crash like that is the runtimes not being installed on your client's PC. Does your install package install the MSVC runtimes? If not, have you installed the MSVC redistributable runtimes on that PC?
"I have wrote a program which tries to write a file in C:\windows\ directory. "
That's your problem right there. Don't do that.
Edit: This problem only occurs on windows 7 and vista from what I've heard.
I have a very simple app developed with an external graphics library. If I install this app into a program files directory and run it, it will crash immediately but it works fine normally, with exactly the same files. I have realised it is because you need to run the application as administrator for it to work.
I appreciate if this is a problem directly related to the graphics engine I am using, but I don't really think so (but I'm clueless). Can anyone help me?
Edit for more detail:
The application executable and files that are needed to run it are installed into the default program directory - for me, C:\Program Files (x86). If you try and run with without clicking run as administrator, it will simple freeze and say "App has stopped working. Windows is checking for a solution to the problem..." My question is basically, how can I make it so run as administrator isn't necessary?
When a program cannot perform an operation, it (the operation) should fail gracefully. My guess is your application is attempting to do something that it cannot do as a normal user and then fails to check for a return code, and then subsequently crashes. You need to identify what it is your program is doing that it should not be able to do as a normal user. For example (off the top of my head):
Write a file to Program Files (x86)
Write to HKLM
(Without more details) The problem is most likely related to the fact that your program tries to write into the directory and then excepts the file creation/modification to actually have an effect. UAC prevents applications from writing the Program Files directories without administrator privilages. The solution is to redesign your application to not rely on such behavior or store the files in question in one of the intended locations (AppData, etc. folders).
If you right-click on the EXE and go to Properties -> Compatibility there are some options that might help. You could try running the app in compatibility mode for a previous Windows version or if that doesn't work at least mark the EXE to run as administrator by default.
Gosh, this is so weird, I don't know what to say. The short version is that I have a simulator app which I spawn from my application when the user asks me to. It recently stopped working, though I can run the simulator fine from the command line or Start menu. This could be due to moving to VS2010 or Windows 7 or something I didn't notice reviewing source control diffs.
I have a second simulator which I try to spawn in the same fashion and it works fine.
By default, I'm using Qt3's QProcess wrapper around CreateProcess for this purpose, but I get the same behavior using system, my own CreateProcess, and ShellExecute.
ShellExecute of a cmd.exe "/c application params" does provide me with some more information however. I get the dialog
"The program can't start because MSVCR80.dll is missing from your computer. Try reinstalling the program to fix this problem."
Inconveniently, both the parent application and the second simulator use MSVCR80.dll.
Upon copying MSVC*80.dll from g:\windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.4927_none_d08a205e442db5b5 to the same directory as my executable, the error message changes to
"Runtime Error!
Program: g:\path\to\app.exe
R6034
An application has made an attempt to load the C runtime library incorrectly.
Please contact the application's support team for more information.
Followed by
The application was unable to start correctly (0xc0000142). Click OK to close the application.
And, once again, the application runs fine from the command line with those dlls in place.
Update:
I suspected perhaps it was environment related, so changed my ShellExecute mechanism to do cmd /c set && app params. I set up a cmd.exe with those same params and my app is now crashing similarly. Will update when I figure out why :)
It is MATLAB's component runtime tool that is modifying my process's PATH variable to bad effect. It is prepending its own dir full of dll's and wreaking havoc.
A foolish tool I was using did a setenv on PATH, prepending a directory it wanted for dynamically loading some dlls, but which messed up my application later. I ended up using GetEnvironmentStrings as shown in the last example here, erasing the first entry in the PATH env var, and sending the new (original) environment to QProcess, which wraps CreateProcessA.
You need to install the CRT
This may work - if it breaks, you get to keep both pieces :-)
Try installing VC++ redistributable from here - http://www.microsoft.com/downloads/en/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2&displaylang=en.
Remember to backup your system, create a restore point etc. before installing stuff.
Another idea -try reinstalling the failing appliacation itself. It may come with its own copy of VC++ redistributables, and reinstalling might help. Esp. trying to reinstall it using Windows 7's compability mode (perhaps go back to Vista or XP compatibility) might be even more effective.
To reiterate - you'll have to try, and I've no real idea if either of the above ideas will do you good, or even be sure to do no harm. That said, if I were faced with a similar problem, these are the steps I'd try. HTH!