[Bug] Eagle leaking UDP sockets

[Anonymous]

Hi.

I had Eagle running all day, and when returning to my laptop, i tried to open a project in Eagle, and i got a message the Eagle had run out of file descriptors.

Restarted Eagle and had a look at what open file descriptors it had, and I saw a bunch of UDP sockets open, after having had Eagle running for some time Eagle allready had 350+ open sockets all ready, and they don't register in the network stack, so they are not outound connections.

They seem to be opened at a rate of about 1 new socket every 10 seconds.

So I guess that with a system limit of 1024 open file descriptors per process, that Eagle will run out of file decritors after about 170 min, and then it won't be able to open any file from that point on and will have to be restarted 😕

Running Eagle 8.0.0 on ArchLinux

[Anonymous]

Apparently I can't edit my original post 😕

But when Eagle reaches 944 open UDP sockets it stops being able to open previews of projects.

And trying to open any folder (eg. the folder with libraries, or ULP scripts) doesn't show anything at all, which it did priviously.

So with some math we can see how long Eagle will work before failing:

    944 sockets * 10 sec. per socket = 9440 seconds

    9440 / 60 = 157,33 minutes

So after just over 2 and a half hour you wont be able to use Eagle any more, and depending on how the file handling is done in Eagle, you might not even be able to save your project to do the restart.

The numbers above is just for Eagle to sit idle in the background.

So if I was actively using Eagle in a design, ther would proberbly also be file descriptor usage for opening library file as well, so it would go even faster for Eagle to be none usable 😕

Any body else that has seen this ?

[Anonymous]

Ok, have been looking further into this, as the AutoDesk people might be on weekend.

I have found the use for the UDP sockets, and it's used to check if a network interface i up.

First they create a UDP Socket, and recives a filedescriptor (see number in bold below) from the kernel, and sends queries to the kernel via ioctl()

   [00007ff663ec29e7] socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 20<UDP:[35913606]> <0.000014>

   [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFCONF, {1024 => 5 * sizeof(struct ifreq), [{ifr_name="lo", ifr_addr={sa_family=AF_INET,

        sin_port=htons(0), sin_addr=inet_addr("127.0.0.1")}}, {ifr_name="wlp6s0", ifr_addr={sa_family=AF_INET, sin_port=htons(0),

        sin_addr=inet_addr("192.168.1.11")}}, {ifr_name="vz-network1", ifr_addr={sa_family=AF_INET, sin_port=htons(0),

        sin_addr=inet_addr("169.254.220.39")}}, {ifr_name="vz-network1", ifr_addr={sa_family=AF_INET, sin_port=htons(0),

        sin_addr=inet_addr("10.0.0.1")}}, {ifr_name="vz-network1", ifr_addr={sa_family=AF_INET, sin_port=htons(0), sin_addr=inet_addr("10.0.1.1")}}]})

            = 0 <0.000022>

    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFFLAGS, {ifr_name="lo", ifr_flags=IFF_UP|IFF_LOOPBACK|IFF_RUNNING}) = 0 <0.000008>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFFLAGS, {ifr_name="wlp6s0", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0 <0.000012>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFHWADDR, {ifr_name="wlp6s0", ifr_hwaddr=c8:ff:28:ef:62:bd}) = 0 <0.000008>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFFLAGS, {ifr_name="vz-network1", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0 <0.000007>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFHWADDR, {ifr_name="vz-network1", ifr_hwaddr=12:d1:8c:66:1d:27}) = 0 <0.000009>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFFLAGS, {ifr_name="vz-network1", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0 <0.000008>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFHWADDR, {ifr_name="vz-network1", ifr_hwaddr=12:d1:8c:66:1d:27}) = 0 <0.000007>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFFLAGS, {ifr_name="vz-network1", ifr_flags=IFF_UP|IFF_BROADCAST|IFF_RUNNING|IFF_MULTICAST}) = 0 <0.000007>
    [00007ff663eb9ac7] ioctl(20<UDP:[35913606]>, SIOCGIFHWADDR, {ifr_name="vz-network1", ifr_hwaddr=12:d1:8c:66:1d:27}) = 0 <0.000007>

But where do you close that file descriptor again ????

Then after about 10 sec you get a new filedescriptor (in bold again):

    [00007ff663ec29e7] socket(AF_INET, SOCK_DGRAM, IPPROTO_IP) = 22<UDP:[35913607]> <0.000010>

Which is still not being closed, and the cycle continues.

Why do you need to check if there is a network connection every 10 seconds, I find that kinda excessive, especially for battery powered devices, why not only check for connectivity during startup/sigin, because, you wont need the network for the next 14 days anyway (?), or when network activity is required for some function, and most people probably don't have eagle running for 14 days straight any way i guess.

[Anonymous]

Another issue I just discovered.

Why the fsck, do you keep writing the config file every 10 seconds, that is just insane !!!!

That results in wearing down my SSD unneeded god damit, write it once at startup/signin, shutdown, maybe even once a day or week and be done with it, instead of this ****.

[JuergenGe]

Could not check it in detail, but the program shuts down after a bunch of hours with the error:

Error u40
Error u10

I guess this is caused by the same issue niki discovered.

[Anonymous]

Hi Jürgen.

I have seen those too, but it haven't had an effect on my end that I have noticed.

The only crashes I have had is when playing with the content in eagle-8.0.0/lib, might look into theese too when I'm gonna try debugging my printing issue that I have in Eagle.

[jorge_garcia]

Hello niki,

Thank you for reporting this bug, the devs have made a ticket for it and we hope to have it resolved for our next update which should be out very soon. They have confirmed that currently it is a linux only error and that they will be increasing the time interval between calls as well as fixing the original issue.

Let me know if there's anything else I can do for you.

Please accept as solution if my post fully resolves or you issue, or reply with additional details if the problem persists

Best Regards,
Jorge Garcia

[Anonymous]

Hi Jorge.

How long is "very soon" ?

Please try to be more specific, for this kinda bug, I would expect an update within a week.

[jorge_garcia]

Hi Niki,

I'm still figuring out how much I'm allowed to say without accountants attacking me. The solution is in the neighborhood of the time you have proposed.

I hope that gets the point across without being too specific.

Best Regards,

[Anonymous]

Okay, so probably something like early next week then.

Have you relayed may solution proposal to the the ticket ?

1) Close the UDP socket when your done with it.

2) Only check for network connectivity when a network is required.

3) Write the configuration file (the one with the license information) once at startup/signin, shutdown and maybe even once a day or every 2nd to 3rd day if Eagle is running continuesly without being shutdown or something like that ?

Okay, time to look at my next bug in a new thread.

[jorge_garcia]

Hi Niki,

The devs themselves checked the thread. Thank you for participating, it would've been nice to have you on our old forum but I'm glad you are here now.

Best Regards,

[Anonymous]

That sound great 🙂

The worst kind of information is second hand information with regards to debugging 😉

How long I will remain will be seen, I'm still evaluating Eagle and Autodesk for that matter.

And I'm used to Open Source Software, so it's kinda weired to have your hands tied, by not having access to the source code, and can't do anything other than wait to see what happens, when your used to getting your hands dirty 😉