Parts won't drop into editor


#1

Steps I took that resulted in the problem:

I started fritzing selected new, then tried to drop a resistor (or any part) onto the workspace. As soon as you move the mouse the part disappears. This is true in all views (breadboard, schematic and PCB).

I have tried the fedora download version on the downloads page. I have used the latest from git repo.

What I have just done is run Fritzing as root - and this works. So what permissions might be a problem for this?

What I expected should have happened instead:

The part should stay. An error message would be useful to be able to correct the issue.

My version of Fritzing and my operating system:

Fedora 31

Please also attach any files that help explaining this problem


#2

Did you by chance use sudo to install Fritzing? If so delete the install and the user directories and reinstall as a normal user (that is what Fritzing is expecting.) It is also better to install from the tarball on the Fritzing site rather than the OS repository as various of the repositories have problems (often not including the parts repo as a dependency in the past.) Probably the first thing to try (because it is easiest) is removing the user directories, Fritzing will then recreate them with the permissions it wants.

There are two user directories (with your parts and the parts database) which don’t get touched during an install (to not affect your sketches during upgrades). On Windows they are in

c:\users\username\AppData\Fritzing\roaming\Fritzing (which is a hidden directory so you need to enable hidden directories in explorer) and

c:\Users\username\My Documents\Fritzing (where username is your windows id)

If you don’t have any parts or sketches you want to keep you can just delete those two directories and Fritzing will recreate them, or you can move them aside by renaming them if you wan to keep something in them.

linux

~/Documents/Fritzing/parts
~/.config/Fritzing

Mac

/Users/username/Documents/Fritzing/parts
~/.config/Fritzing

Peter


#3

Hi Peter,

Thanks for the reply. I deleted those driectories and also ran sudo /usr/bin/uninstall_fritzing.sh. I then ran ./install_fritzing.sh as the user from the source folder of Fritzing.

Any other ideas?

KR

Nick


#4

Which version are you running? 0.9.3B or 0.9.4? On 0.9.3b I usually get the tar ball from the Fritzing download site and then untar and run it by executing the Fritzing binary (no install.) I haven’t yet tried the new 0.9.4 on Linux (only Windows so far.) Sounds like there is a permissions problems somewhere, but I’m not sure where, possibly the temp files that get created on the fly, but I would expect those to be created as the user with an appropriate umask. You might want to try the debug log (although it usually doesn’t help with permission problems) Help->Enable debugging log, which creates a debug window which tracks progress through the code (in a very cryptic manner :slight_smile: )

Edit:

Something that may work better than debug:

change in to the Fritzing directory then

strace -o strace.out ./Fritzing

when Fritzing fails the strace.out file should have the name of the file (although it may be hard to find :slight_smile: look for something with a non zero return code) that is causing problems. If you either delete it or change its permissions things should get better. I suspect that there is a file that has the wrong permissions that isn’t getting deleted by what we have done so far. That should be a temp file which I would expect to have been deleted by a reboot (when tmp is cleared) but it may be in some odd directory.

Peter


#5

Hi Peter,

Thanks for your answer. The current version I have is 0.9.5 beta. But I on;y cloned this from github when I came across this problem - which was from a bundled download.

I just spent a bit of time using strace (I did have a peak before at this but it is very verbose!). I ran as root and my user account and the root version does appear a little quieter, but for the moment I cannot figure out the main differences and if they are important or not.

I’ll try and get a bit more time on this sometime and comme back.

Thanks

Nick


#6

If you use the development version of Fritzing, please use github for any issues. The “uninstall fritzing” script is currently untested, and not part of the official release.


#7

Grep should help with that. Try this (the original command isn’t useful because it only traces the initial command):

strace -o …/ouptut/read -ff ./Fritzing

(the -ff in the command traces forks) then there will be a lot of files of the form read.123 where the .123 is the pid of the forked task. You need to create a directory output beside the Fritzing directory (to keep the strace files somewhere easy to delete without deleting Fritzing!) for the …/output above to work. Then

grep open …/output/read* | grep ‘= -’

should get you only the file open calls which fail (negative return codes usually indicate failure.) One of those should be the file that is causing the failure, and the file name should be in the command line so you can look at its permissions. I suspect you will find something that is owned by root from the initial install that isn’t being deleted by anything we have done so far.

edit: Come to think of it, you probably need to change open to write above. If you have read permission (which is likely) the open will work but the write will fail, so we need to be looking at the write system calls not open.

edit2:

Another late thought: if you have not already done so, do an ls -laR on the Fritzing install directory and the two user directories to make sure all the root owned files and directories were actually deleted. If any of the files or directories in any of the 3 directories are owned by root rather than your user ID this type of error will occur. That seems more likely than a temp file somewhere to me.

Peter


#8

I have exactly the same problem.

If I execute the Fritzing from command line some additional information appears:

QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
QWaylandShmBuffer: mmap failed (Invalid argument)
qt.svg: Duplicate unique style id: “SVGID_1_”
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()

The 3 latest messages appear just right after dropping a component into one of the views.


#9

Which Fritzing version and operating system? How was Fritzing installed (if this is linux, did you use an OS supplied package or the tar ball from the Frtizing download site?) The error messages are from Qt which is the graphics platform, and I don’t recognize them, so they may or may not be the cause (alhough they look some what likely in that they look to be making a request for something. The original poster looks to have used sudo for the install which has likely left some files owned by root.

Peter