[SRU] eagle crashes on several user actions

[sigvdr]

Binary package hint: eagle

Zoom into schematic or board using the select button and define the new size with mouse result in a crash of eagle.

ProblemType: Bug
Architecture: i386
Date: Thu Nov 5 22:43:59 2009
DistroRelease: Ubuntu 9.10
Package: eagle 5.4.0-4ubuntu1
ProcEnviron:
 LANG=de_DE.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: eagle
Uname: Linux 2.6.31-14-generic i686

______________________________________

Here is the formal SRU request:

1) This program is will load and run in karmic. However, when you try to zoom on a schematic, it will crash.

2) This has been addressed in the development branch upstream with this exact fix. I cherry-picked it from a later release.

3) Attached is the minimal patch (3 lines are added to debian/bin/eagle wrapper file).

4) Test case:
1) load eagle
2) open a schematic or board
3) try to zoom
4) BOOM!

5) Regression potential: none. All this patch does is copy a file to ~/.eagle/bin Nothing is deleted or removed.

[Scott Howard (showard314)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 subscribe me

Thank you for your report and helping make Ubuntu better.

Could you try the following and see if you can zoom:

cp /usr/lib/eagle/bin/eagle ~/.eagle/bin/

that's from:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546237

If so, we can cherry pick that fix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.9)

iD8DBQFK800juqVp0MvxKmoRAirEAJ9zhIdAX4JjPvOU282zkjqPfOty7QCghaMJ
Gn9Orh5gA9234ohpYjGvojI=
=1PLH
-----END PGP SIGNATURE-----

[Scott Howard (showard314)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

 subscribe showard314

Thank you for your report and helping make Ubuntu better.

Could you try the following and see if you can zoom:

cp /usr/lib/eagle/bin/eagle ~/.eagle/bin/

that's from:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546237

If so, we can cherry pick that fix.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (MingW32)
Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.9)

iD8DBQFK81bauqVp0MvxKmoRAuYKAJ95YXxE7wDOuOlOLD0MWxxQbMidcwCg2q5o
Sf1dRgBxEaaCZ2BulKp+71M=
=gN3I
-----END PGP SIGNATURE-----

[sigvdr (sig)]

I have done

cp /usr/lib/eagle/bin/eagle ~/.eagle/bin/

and now i can zoom without a crash.

Scott Howard wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> subscribe showard314
>
> Thank you for your report and helping make Ubuntu better.
>
> Could you try the following and see if you can zoom:
>
> cp /usr/lib/eagle/bin/eagle ~/.eagle/bin/
>
>
> that's from:
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546237
>
>
> If so, we can cherry pick that fix.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Use GnuPG with Firefox : http://getfiregpg.org (Version: 0.7.9)
>
> iD8DBQFK81bauqVp0MvxKmoRAuYKAJ95YXxE7wDOuOlOLD0MWxxQbMidcwCg2q5o
> Sf1dRgBxEaaCZ2BulKp+71M=
> =gN3I
> -----END PGP SIGNATURE-----
>
>

[sigvdr (sig)]

I have done

cp /usr/lib/eagle/bin/eagle ~/.eagle/bin/

and now i can zoom without a crash.

[Scott Howard (showard314)]

Thanks! needs a merge to 5.6.0-3 from debian, I'll work on it.

[Scott Howard (showard314)]

Here is the formal SRU request:

1) This program is will load and run in karmic. However, when you try to zoom on a schematic, it will crash.

2) This has been addressed in the development branch upstream with this exact fix. I cherry-picked it from a later release.

3) Attached is the minimal patch (3 lines are added to debian/bin/eagle).

4) Test case:
1) load eagle
2) open a schematic or board
3) try to zoom
4) BOOM!

5) Regression potential: none. All this patch does is copy a file to ~/.eagle/bin Nothing is deleted or removed.

[Scott Howard (showard314)]

See attached branch for merge and .diff patch.

[John Dong (jdong)]

Hmm. This is admittedly one of the most unusual fixes that I've reviewed. Can someone take a stab at explaining why the binary needs to be copied to the user's home directory?

[Scott Howard (showard314)]

I took this fix line from line from Debian (see the bug report).

What the debian maintainer is doing is creating ~/.eagle which contains symlinks to all the "data" in /usr/share/eagle and contains a copy (not a symlink) of /usr/lib/eagle/bin/eagle.

His original package included the symlinks, but he didn't include the executable. He updated the package on Oct 19 to include the fix we have here.

I believe he does this because the binary (which is non-free and precompiled) expects to be run in the same folder as the data, but Debian policy doesn't let you put executable wrapper or bins inside /usr/share/ .

This is my guess from detective work looking at the package. There are probably other ways of doing it (I packaged something for Debian where I place all the binaries in /usr/bin and then wrote a wrapper which just cd into /usr/share/<package name> and then called the binaries from there), but this seems valid. He's an experienced DD, and I believe policy pushed him in this direction.

[John Dong (jdong)]

Well I'll accept that explanation, Scott, from a MOTU-SRU standpoint, for both your explanation of why the software requires this to be done in such an odd manner, and the precedence that Debian is doing the same.

I cannot guarantee that that the archive admins accepting the upload will agree though; I'd like their expertise and input on their issue too...

Anytime you're ready, prepare a debdiff for karmic-proposed to look at.

Thanks

[Scott Howard (showard314)]

Thank John, I know SRUs are a very delicate beast, and I appreciate
having all the layers of feedback, actually! I have a bzr diff at
comment #8.

http://launchpadlibrarian.net/35390010/475891fix.diff

Would a debdiff be needed too? (I'm still learning what is acceptable
forms of files, if this is good enough or if a -p1 patch like debdiff
is preferred).

[John Dong (jdong)]

Ah whoops, shame on me for reading slowly. The above diff is fine for motu-sru review though typically a debdiff is preferred by sponsors who will upload the package on your behalf.

At any rate, consider this an ACK from motu-sru for the above debdiff with its versioning.

archive admins: As was done with zsync by slangasek, I think this is a good candidate for copying from karmic-proposed --> lucid.

[Scott Howard (showard314)]

Sure thing, here's the debdiff (I was away and couldn't make it at the time, that's what I asked)

[Fabrice Coutadeur (fabricesp)]

Hi,

Sorry about that, but I'm not able to reproduce this problem in a karmic chroot (not even the problem described in Debian).
Can you explain a bit more how to reproduce the bug?

Thanks,

Fabrice

[Scott Howard (showard314)]

Thanks again Fabrice! LaserJock has been helping me with this one,
we've been discussing it off-LP. It turns out it is a bug on upgrade;
fresh installs don't see this problem. Since a work around exists
(copying the file) and a fresh install should also fix it, should we
even follow through with an SRU? Merging/syncing with Debian (the
other bug you're looking at for me in eagle) will include this fix in
Lucid.

I mentioned this on the other bug, this package has been RFA-ed in
Debian, so it is in need of some love. I'm hoping to get this package
running at 100% in Lucid and possibly adopt it in Debian. (Although
it's non-DFSG, I'd call this the industry standard for PCB designing,
in my opinion it shouldn't be overlooked as a package and could use
some love)

[Peter Clifton (pcjc2)]

I couldn't resist chiming in here.. even though I know it is inappropriate.

Not to detract from it, but I wouldn't call Eagle _the_ industry standard for PCB design. Protel, Altium, PADs, OrCad...?
Eagle is very popular with hobbyists, and is important to see its package working on Ubuntu from a QA point of view.

Fortunately we also have some nice open source EDA packages in Ubuntu as well.. Kicad and gEDA + PCB. (I'm biased
there, as I'm a gEDA / PCB developer).

Both of the above open source packages are seriously competitive with Eagle (assuming no design legacy to support).
I wonder how we can better advertise their presence to new converts.

[Scott Howard (showard314)]

I apologize: the best part of the FOSS world is both choice and the
freedom to contribute, add, change the code. The major downside of
eagle is that it is not FOSS, and I wholly encourage others to try to
find which one they like best (especially FOSS choices). However, at
work, I must use Eagle, and I fear others also lack that choice at
work.

[Fabrice Coutadeur (fabricesp)]

putting back as new to get some motu-sru feedback according to the last comments (jdong? :-) )

[John Dong (jdong)]

Uhhhhh ok..... so why is this only a bug on upgrade, and not fresh install, and what do you mean by a fresh install will fix it? I'd appreciate it if the hand-wavy procedural explanation could be augmented with some technical explanation of the cause of the bug, too.

[Fabrice Coutadeur (fabricesp)]

Hi,

As spoken with jdong iby IRC, let's look for a cleaner solution to this problem for the SRU:
<jdong> I'd say let's try to come up with a more satisfactory explanation of why it's broken
<jdong> before attempting to shove through silly one-liner hacks when we still don't agree what the symptoms are yet :)
<jdong> eventually once we understand the problem enough to make a fix, I would be interestd in a SRU for it

Marking as Incomplete until this happen :-)

Thanks,
Fabrice

[Scott Howard (showard314)]

Agree - I don't like sending hacks up the SRU chain anyways! I'll try
to contact Shaun (the Debian maintainer) and see what the problem was.

[Scott Howard (showard314)]

OK, I think I have a satisfactory answer. In short: previous versions
copied the executable binary to the users home directory, but in newer
versions, the executable binary was moved to /usr/lib so it is no
longer needed to be copied to the home directory. However, if you had
the old version and then upgraded, you STILL had the old binary in
your home directory, which eagle would try to call to and SEG FAULT
whenever you tried to zoom, edit a wire, etc.

LONG VERSION:
The first time you run the closed binary it, it will create it's
freeware license file, and place it in the directory where the
executable was run from. Older Debian versions installed "system
wide," which caused problems since the key and executable were then
owned by root since you had to run as root in order to save the
license file to /usr/share/eagle.

The debian maintainer got around that by "Installing" the program to
~/.eagle by populating it with symlinks to /usr/share/eagle - so now
everything is owned by the user (including the license key). The
Debian wrapper file uses "exec -a" to execute the closed binary from
/usr/lib/eagle/bin as if it was in the directory ~/.eagle/bin/

However, a couple of debian revisions ago, the closed binary was moved
from /usr/share/eagle/bin to /usr/lib/eagle/bin , so it is NO LONGER
copied over to ~/.eagle/bin along with everything else in the wrapper
script.

For some users, that change didn't cause a problem, but for users that
upgraded there is a problem that:
1) they had the OLD closed binary that used to be in
/usr/share/eagle/bin already copied over to ~/.eagle/bin from their
previous installation
2) The desktop menu item and debian wrapper scripts calls the NEW
binary located in /usr/lib/eagle/bin
3) When you try to zoom, edit wire, etc, the running process looks in
~/.eagle/bin for the compiled functions ----- BUT that is the OLD
binary! (SEG FAULT!)

Why it works for us "new installation" people: we don't have ANY
closed binary in ~/.eagle/bin so it looks in our /usr/lib directory
and finds the proper binary

I think I'm satisfied with that explanation :-)

I pulled that info from the following bug reports:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=450529
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=535868
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=546237
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=392414

By the way, I'm in mentors.debian.net to adopt this package, if you
are a DD that can sponsor it, I'd appreciate it (the server is down,
but do a package search for "Eagle")

[John Dong (jdong)]

Scott,

This explanation makes a lot of sense and I'll buy it.

Now, I think the correct fix would have to be a wrapper for the eagle binary that detects the presence of a mismatched ~/.eagle/bin and offers to delete it upon startup, or to stop Eagle from attempting to load things from the user's home directory.

Copying the new binary to the home directory would just prolong the problem.

[Fabrice Coutadeur (fabricesp)]

Good explanation, Scott!

[Scott Howard (showard314)]

@sigvdr: Can you try the following to confirm our theory:
rm ~/.eagle/bin/eagle

and see if the program crashes?

Attached is a debdiff using Jon's most recent comments (delete the offending binary rather than propagating the bug)

[sigvdr (sig)]

I have done
  rm ~/.eagle/bin/eagle ( without using any debdiff )
and the program crashes again. Open schematic -> zoom -> crash

How can i use fixoldbinaryinhome.debdiff ?

[Scott Howard (showard314)]

Thanks for the testing!
One more test:
rm /usr/share/eagle/bin/eagle

and then see if eagle crashes

(if you can't delete that file, could you:
ls /usr/share/eagle/bin/*
and see if anything is there?)

Finally (after the testing) to get functionality back, first try:
ln -s /usr/lib/eagle/bin/* ~/.eagle/bin/

and run the program
if that doesn't work:
cp /usr/lib/eagle/bin/eagle ~/.eagle/bin/

Let me know which combinations of those works

You don't have to worry about the debdiff. All the debdiff is doing is
exactly the commands above (rm ~/.eagle/bin/eagle).

[sigvdr (sig)]

/usr/share/eagle/bin/eagle does not exist, so i can not delete that file.

ln -s /usr/lib/eagle/bin/* ~/.eagle/bin/
Now eagle ask me for a "license.key" . I tried to point to the "freeware.key" in ~/.eagle/bin or /usr/share/eagle/bin, but always i get an error "Could not open eagle.key" .

cp /usr/lib/eagle/bin/eagle ~/.eagle/bin/
Eagle works

[sigvdr (sig)]

The executable binary tries to open ( and save after work ) "eagle.key" in the same path as the binary is started from.
So if you copy the executable binary to /usr/bin and start /usr/bin/eagle you will get an error "can not open /usr/bin/eagle.key",
and for example if you copy the executable binary to /home and start /home/eagle you will get an error "can not open /home/eagle.key".
There is no way to seperate that two files ( executable binary to /usr/.... and eagle.key to /home/.... ) also with symlinks, i found no way.

On a second computer i installed eagle 5.6.0 ( downloaded ftp://ftp.cadsoft.de/eagle/program/5.6/eagle-lin-5.6.0.run )
On this computer i found the executable binary in /usr/bin and the users data in ~/.eagle and no /usr/lib/eagle nor /usr/share/eagle.

[Scott Howard (showard314)]

Thanks for all your help, sigvdr. Your situation seems unique, it may
not be good for an SRU, but I'd still like to get to the bottom of
this!

The debian installation and the binary you download from cadsoft
install the files to different places in order to conform to debian
policy and keeping system installations "uniform" in debian
distributions.

Could you do the following:
find /usr -name eagle > eaglelocs.txt

and upload eaglelocs.txt here? I think there is a binary hiding in
your system somewhere from a previous installation or from installing
the binary from cadsoft. If there is, and we can find it, we can
update the debian package to remove it during installation or justify
copying the executable to the home directory.

[Scott Howard (showard314)]

I just re-read your comment:
"The executable binary tries to open ( and save after work )
"eagle.key" in the same path as the binary is started from.
So if you copy the executable binary to /usr/bin and start
/usr/bin/eagle you will get an error "can not open
/usr/bin/eagle.key",
and for example if you copy the executable binary to /home and start
/home/eagle you will get an error "can not open /home/eagle.key".
There is no way to seperate that two files ( executable binary to
/usr/.... and eagle.key to /home/.... ) also with symlinks, i found no
way."

Thanks for figuring that out, do you have an idea why some users (e.g.
fabrice and I) are able to run the program without segfaulting without
the executable in our /home? The eagle wrapper file we are using just
executes the binary in /usr/lib/eagle in our home directories using
"exec -a"

[sigvdr (sig)]

Result from "find /usr -name eagle"
-------------------------
/usr/bin/eagle
/usr/lib/eagle
/usr/lib/eagle/bin/eagle
/usr/share/eagle
/usr/share/doc/eagle
/usr/share/menu/eagle
--------------------------
This "find" was done on a 64Bit version of Karmic. I remember that i had tried to install a direct downloaded eagle version ( from Cadsoft ) about one or two years ago.

On a second installation of Karmic 32bit ( Installed as Ubuntu 7.10 and step by step upgraded to Karmic ) i had installed the ubuntu eagle4.16 package. With upgrade to Karmic this package changes to eagle5.4.

On both installations i have the same crash behavior.

[sigvdr (sig)]

On a new (3.) installation of Karmic ( not upgraded from older Ubuntu's ) i have the exactly same crash behavior.
Result from "find /usr -name eagle" is the same as shown in the last post.

"do you have an idea why some users (e.g.
fabrice and I) are able to run the program without segfaulting"

All 3 Installations are done at the same Hardware. May be a problem with my integrated grafic "VIA UNICHROME" ?

[Scott Howard (showard314)]

Thank you again for all your help! The original debian maintainer is
away on vacation, so I haven't had his input yet. I don't think it's
the VIA chipset, since copying the file to your home directory fixes
it. The good news is that the newest version of eagle (in lucid and
squeeze) will not have this problem since it copies the file to the
home directory. I'll try to get some input from him, so we at least
understand why we need to copy the file.

[sigvdr (sig)]

There is no problem with the VIA Hardware! I tried eagle on a 4. installation with a different hardware. The problem is exactly the same.

Recapitulation of my older posts:
- start Eagle
- open board and/or schematic
- zoom into detail
- - press a mousekey
- - move to a second position ( i see a gray rect followich the mouse )
- - release the mousekey
- crash ( eagle is closed and terminated )

This behavior is exactly the same on:
- 32 Bit Ubuntu upgrade from 7.10 to 9.10
- 64 Bit Ubuntu upgrade from 8.04 to 9.10
- 32 Bit Ubuntu new installation 9.10
- 32 Bit Ubuntu new installation 9.10 with different Hardware

The next ideas:
- I run eagle with "freeware.key" ! Do you run eagle with an other license key?
- did you install/test the eagle package from a newer inofficial source e.g. "karmic-proposed"

[Scott Howard (showard314)]

The debian maintainer returned from vacation and had this to say about the bug:

"
Eagle looks for its data files in the same directory as the executable
like so (more or less):
prefix=$(dirname $(dirname $(realpath $(which $argv0))))

We can set argv[0] using the -a option of exec. See `help exec`.

You can test this out at the command line:
$ ls -l .eagle/bin/eagle
-rwxr-xr-x 1 sjackman sjackman 11473300 2009-12-14 19:52 .eagle/bin/eagle
$ argv0=~/.eagle/bin/eagle; dirname $(dirname $(realpath $(which $argv0)))
/home/sjackman/.eagle

If we remove the executable from ~/.eagle/bin/eagle, eagle can still
find its data files. However, if argv[0] doesn't actually point to the
real executable, eagle will crash as soon as you use try to move a
wire. I don't know why that is.

At this point, we need to co-operate with upstream to ask them to add
a couple command line options. At the very least, it needs a --datadir
option to point to the data files. An additional --license option
would be very useful. If we had both these options, we could then
launch eagle like so:
eagle --datadir /usr/share/eagle --license ~/.eagle/license.key"

So he doesn't know why this fix works, but it does. I don't know if this would be good enough for the SRU, but unfortunately, with the closed code, I don't know if we can figure out what is going on. I'm working with upstream to see if we could get the above command line options included in future versions.

I'm setting back to "new," however, please reject if you are uncomfortable uploading without understanding the exact reason why the fix works. The fix is in comment #8.

[John Dong (jdong)]

Well I don't feel 100% comfortable with this "workaround" for a SRU but do appreciate the additional explanation from Debian for why it's happening. Definitely an upstream-coordinated "fix" would be the right solution, but in the meantime, I'm torn on this. On one hand, it's a trivial fix, but on the other hand, I'm not sure how we feel about copying binaries into a private home directory on launch.

Can another member of the SRU team chime in?

[Martin Pitt (pitti)]

I don't understand why we have to prolong this madness of copying binaries into ~/.eagle/bin/ (which is wrong for a multitude of reasons). Why can't we instead remove the faulty/obsolete binary from ~/.eagle/bin on startup instead? This might require wrapping the original eagle binary into a shell script wrapper, but at least this will all happen in /usr/, and thus can then be cleaned up for good in lucid.

[Scott Howard (showard314)]

The problem isn't with faulty binary in ~/.eagle/bin (see the above
debugging where we removed all copies of old binaries and it didn't
work, amongst other ideas), the problem is that the upstream
executable needs to have it's license key (this is a non-free program)
in the same directory as the binary. Neither I, nor the previous
maintainer know why it is, and why we can't just use exec -a or
symlinks to "trick" the binary, but that is the way it is (until
upstream responds to my prodding). The first time the binary is
executed, it will create the license key file. If the binary is in
/usr/bin, you need to exec the binary as root, and then you have a
.key file in /usr/bin, which isn't good either. The previous
maintainer came up with the current method of wrapping the original
eagle binary into a bash shell script with creates ~/.eagle and copies
the binary into it and symlinks all the data directories in
/usr/share/eagle-data/, then exec the binary in ~/.eagle/bin. The
license key is now owned by the user and located in the same directory
as the binary.

I contacted upstream and asked them to put command line arguments for
--datadir and --licensedir to avoid this mess. Right now, I'm really
looking for a solution to get this to work, because you are right -
all this copying is madness, I appreciate any ideas on how to clean
this up.

[Scott Howard (showard314)]

it's been 2.5 years and fixed in later releases.