Parts won't drop into editor

bugs
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

10

I am also seeing the same behavior (parts won’t drop) and messages identical to these (I can run wires but not drop components)

I am running Fedora 31 (with qt5-qtbase-5.13.2-2.fc31.x86_64 installed). I used the OS Software library tool to install Fritzing 0.9.2b-19.fc31. I know how to install from source, but I just wanted to a quick scribble-up of a breadboard and a couple of CMOS ICs and didn’t want to go through the entire from-scratch process.

Since I see numerous messages about Wayland and I see at least one other poster here is running Fedora 31, I have to wonder about Qt and Wayland compatibility issues here.

Here’s a stdout capture from my session where I started Fritzing, opened a new project, then tried to place a resistor and one IC (Atmel processor).

QSocketNotifier: Can only be used with threads started with QThread
libpng warning: iCCP: known incorrect sRGB profile
[ message repeats 27 times ]
QWaylandShmBuffer: mmap failed (Invalid argument)
[ message repeats 274 times ]
qt.qpa.wayland: Wayland does not support QWindow::requestActivate()
QWaylandShmBuffer: mmap failed (Invalid argument)
[ message repeats 19 times ]
libpng warning: iCCP: known incorrect sRGB profile

Hundreds of mmap failures in less than 30 seconds.

The error message is likely coming from here…

https://code.qt.io/cgit/qt/qtwayland.git/tree/src/client/qwaylandshmbackingstore.cpp

    // map ourselves: QFile::map() will unmap when the object is destroyed,
    // but we want this mapping to persist (unmapping in destructor)
    uchar *data = (uchar *)
            mmap(nullptr, alloc, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
    if (data == (uchar *) MAP_FAILED) {
        qErrnoWarning("QWaylandShmBuffer: mmap failed");
        return;
    }

It works if I run Fritzing as root:

$ sudo Fritzing
libpng warning: iCCP: known incorrect sRGB profile

[ and only the libpng warning, none of the Wayland messages ]

11

This looks like part of the install got done as root. I’d suggest removing the install and renaming the user directories (on linux those are in

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

and contain your mine parts bin if you have things in it.) I would also install 0.9.4 which is the latest release as 0.9.2 is 2 releases ago. The install should be done without sudo so all the files are writable by the user ID you run Fritzing from. If there are still problems the best bet is to open an issue on github here:

Peter

12

I did the install through the standard Fedora Software tool. The version that was available was 0.9.2. I know it’s old, but it’s what available in the Fedora “app store”.

I did a ‘find ~ -user root’ and none of my files anywhere are owned by root. They are all my files. I get that permissions on Fritzing config and file parts can screw things up but that’s not happening here. What’s happening appears to be Qt5 failures to secure shared memory access with Wayland, not app failures.

There are structural differences between writing an app for X and writing an app for Wayland. It would have been nice if source backwards-compatibility was a goal, but they really wanted to tear things down and start over, so you can’t just “port” the app by changing some includes and recompiling.

If you cannot install Fritzing from a package because that screws up permissions, then the fault is with the .spec file not the app. Packaging installs is not new. It’s not reasonable to tell all users “just build from source”.

In terms of this exact bug, I’m about to put Fedora 31 aside because I’m also having problems with the Displaylink adapter kernel module. It’s probably that 5.4 is too bleeding edge for the amount of effort I want to put into making things work. I’ve grabbed Fedora 30 (six months older) and we’ll see if things are happier there.

I’ve been working with Open Source for decades. I contribute to multiple projects. For this, I just want to scribble down a breadboard layout or two - I already use EagleCAD and KiCAD for serious schematic capture and PCB ordering. I am literally only using Fritzing because I want some breadboard graphics.

13

If you are willing to install outside the app store I’d probably suggest 0.9.3b as it loads everything it wants from the zip file. The 0.9.4 release (which is a completely new tool chain) does not so far although I’m hoping we will go back to that in 0.9.5. However for what you appear to want 0.9.2 should do just fine. You may need to install the parts repository as some of the installer versions don’t have it as a prereq and if it isn’t installed Fritzing won’t run correctly.

Peter

14

I can probably add some information to this. I had the same issue running the flatpak stable release from flathub also on Fedora 31. Which is 0.9.4b. I reported that (only) on the fritzing section of flathub at https://github.com/flathub/org.fritzing.Fritzing/issues/8

The problems seems to be QT and Wayland not mixing well yet. The solution (actually work around) was to tell flatpak to run Fritzing with --env=QT_QPA_PLATFORM=xcb, which overrides the default (new) wayland with the older x11. Problem solved.

Now, I do no know for sure what it would take to get Fedora to run a single application under x11. Flatpak is a wrapper/container, so is easier to specify. There have been notes on the net about running newer Fedora versions under x11 instead of wayland, as a global solution. I do not think much of that, since it affects too many other things. This MIGHT be as simple as (from the command line)

QT_QPA_PLATFORM=xcb Fritzing

If 0.9.4b is good enough, you could use the flatpak + flathub version. Or learn how to turn your own build into a flatpak, then try the xcb/x11 override. There are a couple of gotchas getting Fritzing up on flatpak. Especially if you are not running other flatpak applications. One of the dependency needs a manual install. The following (from my notes) should work.

flatpak remote-add --user --if-not-exists flathub https://dl.flathub.org/repo/flathub.flatpakrepo
flatpak install --user flathub org.freedesktop.Platform
flatpak install --user flathub org.fritzing.Fritzing

I prefer to do the installs in the user instead of system environment. If you get a multiple versions message for the platform, pick the latest (currently 19.08). Then to run

flatpak run --env=QT_QPA_PLATFORM=xcb org.fritzing.Fritzing

which I put in a 2 line fritzing script

#! /bin/sh
flatpak run --env=QT_QPA_PLATFORM=xcb org.fritzing.Fritzing "$@" &