Bug 1281449

Created attachment 1093320 [details]
File: backtrace

Created attachment 1093321 [details]
File: cgroup

Created attachment 1093322 [details]
File: core_backtrace

Created attachment 1093323 [details]
File: dso_list

Created attachment 1093324 [details]
File: environ

Created attachment 1093325 [details]
File: limits

Created attachment 1093326 [details]
File: maps

Created attachment 1093327 [details]
File: mountinfo

Created attachment 1093328 [details]
File: namespaces

Created attachment 1093329 [details]
File: open_fds

Created attachment 1093330 [details]
File: proc_pid_status

Created attachment 1093331 [details]
File: var_log_messages

Another user experienced a similar problem:

This appears every time I logout/login and seems to be Wayland related.

reporter:       libreport-2.6.3
backtrace_rating: 4
cmdline:        /usr/libexec/geoclue -t 5
crash_function: avahi_client_free
executable:     /usr/libexec/geoclue
global_pid:     18688
kernel:         4.3.0-1.fc24.x86_64
package:        geoclue2-2.4.0-1.fc24
reason:         geoclue killed by SIGABRT
runlevel:       N 5
type:           CCpp
uid:            992

Actually I was wrong, I got this error even after logout/login into X session.

Don't see anything wrong in code. Could you try running `/usr/libexec/geoclue -t 5` manually under gdb (this crash should be happening when geoclue timesout on no requests) and see what argument is being passed to avahi_client_free() after it crashes?

Forgot to mention that you want to run geoclue either as root or 'geoclue' user.

Follow-up from IRC, reason it likely works when you run geoclue manually is that Avahi was already activated by some other service but when run automatically on boot or session start was not yet activated.

The patch from jaeckel fixes the crash, by getting the correct client pointer and not assuming it is valid.


To fix Avahi not connecting in this situation, it is possible to have avahi_client_new retry the connection automatically by passing the flag AVAHI_CLIENT_NO_FAIL in flags, see:
http://avahi.org/download/doxygen/client_8h.html#a46a797e5d352f6f98261834ae3b1a3ed

Let me know if using that fixes the issue.

> Follow-up from IRC, reason it likely works when you run geoclue manually is
> that Avahi was already activated by some other service but when run
> automatically on boot or session start was not yet activated.

Doubtful cause Ankit (former SoC student) was able to reproduce both these cases 100% and he tried many times in a row.
 
> The patch from jaeckel fixes the crash, by getting the correct client
> pointer and not assuming it is valid.

Yeah, it does and I'll push it soon but I really would like to fix the actual issue.

 
> To fix Avahi not connecting in this situation, it is possible to have
> avahi_client_new retry the connection automatically by passing the flag
> AVAHI_CLIENT_NO_FAIL in flags, see:
> http://avahi.org/download/doxygen/client_8h.
> html#a46a797e5d352f6f98261834ae3b1a3ed
> 
> Let me know if using that fixes the issue.

I'll ask Ankit to try that out cause I'm unable to reproduce on my F23 machine.

The only thing I can think of, is selinux so can someone try with selinux disabled?

(In reply to Trent Lloyd from comment #17)
> To fix Avahi not connecting in this situation, it is possible to have
> avahi_client_new retry the connection automatically by passing the flag
> AVAHI_CLIENT_NO_FAIL in flags, see:
> http://avahi.org/download/doxygen/client_8h.
> html#a46a797e5d352f6f98261834ae3b1a3ed

I tried this. It just makes it go to 'bad state'.

(In reply to Zeeshan Ali from comment #18)
> I'll ask Ankit to try that out cause I'm unable to reproduce on my F23
> machine.
> 
> The only thing I can think of, is selinux so can someone try with selinux
> disabled?

This didn't help either.

Created attachment 1098933 [details]
nmea-source: Fix avahi daemon not running problem

This was being caused by unintialized priv->avahi_client inside
gclue_nmea_source_init. Initializing priv->avahi_client inside
client_callback fixes this problem.

(In reply to Ankit from comment #21)
> Created attachment 1098933 [details]
> nmea-source: Fix avahi daemon not running problem
> 
> This was being caused by unintialized priv->avahi_client inside
> gclue_nmea_source_init. Initializing priv->avahi_client inside
> client_callback fixes this problem.

Does it? It's really strange. The documentation of avahi_client_new() is confusing as hell. This is what it says about the callback parameter:

"A callback that is called whenever the state of the client changes. This may be NULL. Please note that this function is called for the first time from within the avahi_client_new() context! Thus, in the callback you should not make use of global variables that are initialized only after your call to avahi_client_new(). A common mistake is to store the AvahiClient pointer returned by avahi_client_new() in a global variable and assume that this global variable already contains the valid pointer when the callback is called for the first time. A work-around for this is to always use the AvahiClient pointer passed to the callback function instead of the global pointer."

*** Bug 1285843 has been marked as a duplicate of this bug. ***

(In reply to Zeeshan Ali from comment #22)
> (In reply to Ankit from comment #21)
> > Created attachment 1098933 [details]
> > nmea-source: Fix avahi daemon not running problem
> > 
> > This was being caused by unintialized priv->avahi_client inside
> > gclue_nmea_source_init. Initializing priv->avahi_client inside
> > client_callback fixes this problem.
> 
> Does it? It's really strange. The documentation of avahi_client_new() is
> confusing as hell. This is what it says about the callback parameter:
> 
> "A callback that is called whenever the state of the client changes. This
> may be NULL. Please note that this function is called for the first time
> from within the avahi_client_new() context! Thus, in the callback you should
> not make use of global variables that are initialized only after your call
> to avahi_client_new(). A common mistake is to store the AvahiClient pointer
> returned by avahi_client_new() in a global variable and assume that this
> global variable already contains the valid pointer when the callback is
> called for the first time. A work-around for this is to always use the
> AvahiClient pointer passed to the callback function instead of the global
> pointer."

How about we set priv->avahi_client iff it is null and avahi_client parameter of callback is not null?

(In reply to Ankit from comment #24)
> (In reply to Zeeshan Ali from comment #22)
> > (In reply to Ankit from comment #21)
> > > Created attachment 1098933 [details]
> > > nmea-source: Fix avahi daemon not running problem
> > > 
> > > This was being caused by unintialized priv->avahi_client inside
> > > gclue_nmea_source_init. Initializing priv->avahi_client inside
> > > client_callback fixes this problem.
> > 
> > Does it? It's really strange. The documentation of avahi_client_new() is
> > confusing as hell. This is what it says about the callback parameter:
> > 
> > "A callback that is called whenever the state of the client changes. This
> > may be NULL. Please note that this function is called for the first time
> > from within the avahi_client_new() context! Thus, in the callback you should
> > not make use of global variables that are initialized only after your call
> > to avahi_client_new(). A common mistake is to store the AvahiClient pointer
> > returned by avahi_client_new() in a global variable and assume that this
> > global variable already contains the valid pointer when the callback is
> > called for the first time. A work-around for this is to always use the
> > AvahiClient pointer passed to the callback function instead of the global
> > pointer."
> 
> How about we set priv->avahi_client iff it is null and avahi_client
> parameter of callback is not null?

That doesn't answer my questions. Does this patch actually solves the issue? Why does avahi_client_new() returns a NULL?

(In reply to Zeeshan Ali from comment #25)
> That doesn't answer my questions. Does this patch actually solves the issue?
> Why does avahi_client_new() returns a NULL?

Yeah, it is working for me when I initialize priv->avahi_client inside client_callback. I'm not sure as to why avahi_client_new() returns NULL, but I'm trying to find it out.

(In reply to Ankit from comment #19)
> (In reply to Trent Lloyd from comment #17)
> > To fix Avahi not connecting in this situation, it is possible to have
> > avahi_client_new retry the connection automatically by passing the flag
> > AVAHI_CLIENT_NO_FAIL in flags, see:
> > http://avahi.org/download/doxygen/client_8h.
> > html#a46a797e5d352f6f98261834ae3b1a3ed
> 
> I tried this. It just makes it go to 'bad state'.

'bad state' was the error message that was set after passing flag AVAHI_CLIENT_NO_FAIL.

(In reply to Ankit from comment #27)
> (In reply to Ankit from comment #19)
> > (In reply to Trent Lloyd from comment #17)
> > > To fix Avahi not connecting in this situation, it is possible to have
> > > avahi_client_new retry the connection automatically by passing the flag
> > > AVAHI_CLIENT_NO_FAIL in flags, see:
> > > http://avahi.org/download/doxygen/client_8h.
> > > html#a46a797e5d352f6f98261834ae3b1a3ed
> > 
> > I tried this. It just makes it go to 'bad state'.
> 
> 'bad state' was the error message that was set after passing flag
> AVAHI_CLIENT_NO_FAIL.

error message from where exactly?

Forgot to mention that I tried running avahi-browse and then ran Geoclue. avahi-browse could find the service but Geoclue got null value from avahi_client_new() and displayed error.

(In reply to Zeeshan Ali from comment #28)
> (In reply to Ankit from comment #27)
> > (In reply to Ankit from comment #19)
> > > (In reply to Trent Lloyd from comment #17)
> > > > To fix Avahi not connecting in this situation, it is possible to have
> > > > avahi_client_new retry the connection automatically by passing the flag
> > > > AVAHI_CLIENT_NO_FAIL in flags, see:
> > > > http://avahi.org/download/doxygen/client_8h.
> > > > html#a46a797e5d352f6f98261834ae3b1a3ed
> > > 
> > > I tried this. It just makes it go to 'bad state'.
> > 
> > 'bad state' was the error message that was set after passing flag
> > AVAHI_CLIENT_NO_FAIL.
> 
> error message from where exactly?

After getting error string corresponding to the value of error variable passed to avahi_client_new().

I've pushed a modified version of the attached patch: http://cgit.freedesktop.org/geoclue/commit/?id=73bb65796b30ce9a6e917de951e3058c32900b98

I hope that fixes the actual issue, it worked for Ankit at least when he was able to reproduce this issue. I would still wish if some Avahi dev/expert could shed some light on what might be the issue here.

(In reply to Zeeshan Ali from comment #31)
> I've pushed a modified version of the attached patch:
> http://cgit.freedesktop.org/geoclue/commit/
> ?id=73bb65796b30ce9a6e917de951e3058c32900b98
> 
> I hope that fixes the actual issue, it worked for Ankit at least when he was
> able to reproduce this issue. I would still wish if some Avahi dev/expert
> could shed some light on what might be the issue here.

Wouldn't it be better if you set priv->avahi_client inside _init() and override its value if no error has occurred inside client_callback and priv->avahi_client is not already NULL?

Created attachment 1100572 [details]
nmea-source: Init client from callback

Apparently, sometimes avahi_client_new() can simply return a NULL
pointer and you get the real client pointer from the client callback
parameter. Let's initialize our client pointer from client callback
as a fallback.

(In reply to Ankit from comment #32)
> (In reply to Zeeshan Ali from comment #31)
> > I've pushed a modified version of the attached patch:
> > http://cgit.freedesktop.org/geoclue/commit/
> > ?id=73bb65796b30ce9a6e917de951e3058c32900b98
> > 
> > I hope that fixes the actual issue, it worked for Ankit at least when he was
> > able to reproduce this issue. I would still wish if some Avahi dev/expert
> > could shed some light on what might be the issue here.
> 
> Wouldn't it be better if you set priv->avahi_client inside _init() and
> override its value if no error has occurred inside client_callback and
> priv->avahi_client is not already NULL?

Hmm.. sure! Your patch needs to be rebased though (and commit log updated too).

Created attachment 1103912 [details]
nmea-source: Re-init client as fallback only

Since avahi_client_new documentation says that callback function
can be called multiple times after avahi_client_new is called,
we wouldn't want to initialize client inside callback multiple
times. Instead we intialize the client from avahi_client_new
and re-initialize it inside callback function if the client
returned by avahi_client_new is NULL.

Created attachment 1103917 [details]
nmea-source: Re-init client as fallback only

Since avahi_client_new documentation says that callback function
can be called multiple times after avahi_client_new is called,
we wouldn't want to initialize client inside callback multiple
times. Instead we intialize the client from avahi_client_new
and re-initialize it inside callback function if the client
returned by avahi_client_new is NULL.

While we still don't have any explanation of this weird avahi behaviour, the fixes in the new release (which has already been packaged for rawhide) should fix the issue.

This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle.
Changing version to '24'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 24 changed to end-of-life (EOL) status on 2017-08-08. Fedora 24 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days