netatalk-devel — Netatalk development mailing list (for developers)

Re: [Netatalk-devel] netatalk-doc copyright and license

[Daniel M. <mar...@gm...>]

To answer my own question: This is the closest to a COPYING notice we have
in the repo.
https://github.com/Netatalk/netatalk-doc/blob/master/manual/manual.xml
"This documentation is distributed under the GNU General Public License
(GPL) version 2."



On Wed, Jan 11, 2023 at 2:09 PM Daniel Markstedt <mar...@gm...>
wrote:

> A question for you all who have been part of this project for a long time:
>
> I was browsing the netatalk-doc <https://github.com/Netatalk/netatalk-doc>
> repo on Github earlier and couldn't spot any COPYING notice or any other
> mention of license or distribution terms.
> Was this entire repo implicitly distributed under a particular license
> back on SourceForge?
> It would be great to be able to reuse some of these resources under FLOSS
> terms.
>
> Thanks!
> Daniel
>

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Hauke F. <hf...@sp...>]

On Wed, 18 Jan 2023 14:03:52 -0800, Daniel Markstedt wrote:
> Looking at the three release artifacts for 2.2.7, it's only the
> bootstrapped tarball (netatalk-2.2.7.tar.gz) that is missing the
> "openssl_compat.h" header.
> If it's too much of a bother to manually fix that tarball, perhaps you may
> want to just delete it?
> In this day and age, running bootstrap is hardly a tiring activity for most
> computers.

With my package builder cap on, I like me a proper release tarball, and 
having to have the entire autohell installed just to build a package 
(which is the default in pkgsrc) is kind of annoying.

Just make it a 2.7.1 release.  ;)

Cheerio,
Hauke

-- 
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-21344

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Daniel M. <mar...@gm...>]

Ralph,

Looking at the three release artifacts for 2.2.7, it's only the
bootstrapped tarball (netatalk-2.2.7.tar.gz) that is missing the
"openssl_compat.h" header.
If it's too much of a bother to manually fix that tarball, perhaps you may
want to just delete it?
In this day and age, running bootstrap is hardly a tiring activity for most
computers.

Best,
Daniel

On Wed, Jan 11, 2023 at 6:55 AM Andrew Bauer <kni...@ou...>
wrote:

> Thanks Ralph,
> My own personal preference is github as well. I too find it much easier to
> work with. However, I could certainly stay with sourceforge if that is what
> the community wishes.
>
> Whatever the decision may be, I'd ask that an obvious notice be added to
> the obsoleted repository, to avoid confusion as to which repo is
> authoritative.
>
> Thanks,
> Andy
>
> No Trees were killed in the sending of this message.
> However, a large number of electrons were terribly inconvenienced.
>
> ------------------------------
> *From:* Ralph Boehme
> *Sent:* Wednesday, January 11, 2023 8:45 AM
> *To:* Andrew Bauer; Daniel Markstedt; Hauke Fath
> *Cc:* net...@li...; Hauke Fath
> *Subject:* Re: [Netatalk-devel] Moving Netatalk Releases to github?
>
> Howdy!
>
> This is still an open question. I'd favor the move as releasing via
> github is much less hassle and SF is a dead horse anyway.
>
>
> Cheers!
> -slow
>
>
> On 1/11/23 15:35, Andrew Bauer wrote:
> > I apologize if I missed it, but was the original question, asking
> > whether new releases have been moved to github, been answered?
> >
> > I manage the netatalk packages for fedora and epel. Right now fedora and
> > epel branches are looking at sourceforge for new release notifications.
> > I can certainly change that, but I'd like to be certain before I do.
> >
> > Thanks,
> > Andy
> >
> > No Trees were killed in the sending of this message.
> > However, a large number of electrons were terribly inconvenienced.
> > ------------------------------------------------------------------------
> > *From:* Daniel Markstedt <mar...@gm...>
> > *Sent:* Tuesday, January 10, 2023 4:23 PM
> > *To:* Hauke Fath <hf...@sp...>
> > *Cc:* net...@li...
> > <net...@li...>; Hauke Fath
> > <ha...@es...>
> > *Subject:* Re: [Netatalk-devel] Moving Netatalk Releases to github?
> > PR for getting rid of the OpenSSL 1.0 header here:
> > https://github.com/Netatalk/Netatalk/pull/183
> > <https://github.com/Netatalk/Netatalk/pull/183>
> >
> > On Tue, Jan 10, 2023 at 1:35 PM Hauke Fath <hf...@sp...
> > <mailto:hf...@sp... <hf...@sp...>>> wrote:
> >
> >     On Tue, 10 Jan 2023 13:32:52 -0800, Daniel Markstedt wrote:
> >      > Aha, of course, they mustn't have been added to whatever "make
> dist"
> >      > mechanism is used in this project.
> >
> >     I have patched out the #include for pkgsrc net/netatalk22 -- the
> >     package has a dependency on openssl 1.1, so the 1.0 compatibility is
> >     never used.
> >
> >     But the source tarball should be consistent.
> >
> >     Cheerio,
> >     Hauke
> >
> >     --
> >           The ASCII Ribbon Campaign                    Hauke Fath
> >     ()     No HTML/RTF in email            Institut für
> Nachrichtentechnik
> >     /\     No Word docs in email                     TU Darmstadt
> >           Respect for open standards              Ruf +49-6151-16-21344
> >
> >
> >
> > _______________________________________________
> > Netatalk-devel mailing list
> > Net...@li...
> > https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>
>

[Netatalk-devel] netatalk-doc copyright and license

[Daniel M. <mar...@gm...>]

A question for you all who have been part of this project for a long time:

I was browsing the netatalk-doc <https://github.com/Netatalk/netatalk-doc>
repo on Github earlier and couldn't spot any COPYING notice or any other
mention of license or distribution terms.
Was this entire repo implicitly distributed under a particular license back
on SourceForge?
It would be great to be able to reuse some of these resources under FLOSS
terms.

Thanks!
Daniel

[Netatalk-devel] CVE-2022-45188 and CVE-2022-22995

[Andrew B. <kni...@ou...>]

Hello -

These CVE's were reported against the fedora netatalk 3.0.13 package:

CVE-2022-45188 netatalk: heap-based buffer overflow resulting in code execution via a crafted .appl
https://nvd.nist.gov/vuln/detail/CVE-2022-45188

CVE-2022-22995 netatalk: default configuration allows the arbitrary writing of files
https://nvd.nist.gov/vuln/detail/cve-2022-22995

Have either of these been addressed in the recent 3.0.14 release? I do not see direct mention of these CVE's in the release notes on github.

Thanks,
Andy

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Andrew B. <kni...@ou...>]

Thanks Ralph,
My own personal preference is github as well. I too find it much easier to work with. However, I could certainly stay with sourceforge if that is what the community wishes.

Whatever the decision may be, I'd ask that an obvious notice be added to the obsoleted repository, to avoid confusion as to which repo is authoritative.

Thanks,
Andy

No Trees were killed in the sending of this message.
However, a large number of electrons were terribly inconvenienced.

________________________________
From: Ralph Boehme
Sent: Wednesday, January 11, 2023 8:45 AM
To: Andrew Bauer; Daniel Markstedt; Hauke Fath
Cc: net...@li...; Hauke Fath
Subject: Re: [Netatalk-devel] Moving Netatalk Releases to github?

Howdy!

This is still an open question. I'd favor the move as releasing via
github is much less hassle and SF is a dead horse anyway.


Cheers!
-slow


On 1/11/23 15:35, Andrew Bauer wrote:
> I apologize if I missed it, but was the original question, asking
> whether new releases have been moved to github, been answered?
>
> I manage the netatalk packages for fedora and epel. Right now fedora and
> epel branches are looking at sourceforge for new release notifications.
> I can certainly change that, but I'd like to be certain before I do.
>
> Thanks,
> Andy
>
> No Trees were killed in the sending of this message.
> However, a large number of electrons were terribly inconvenienced.
> ------------------------------------------------------------------------
> *From:* Daniel Markstedt <mar...@gm...>
> *Sent:* Tuesday, January 10, 2023 4:23 PM
> *To:* Hauke Fath <hf...@sp...>
> *Cc:* net...@li...
> <net...@li...>; Hauke Fath
> <ha...@es...>
> *Subject:* Re: [Netatalk-devel] Moving Netatalk Releases to github?
> PR for getting rid of the OpenSSL 1.0 header here:
> https://github.com/Netatalk/Netatalk/pull/183
> <https://github.com/Netatalk/Netatalk/pull/183>
>
> On Tue, Jan 10, 2023 at 1:35 PM Hauke Fath <hf...@sp...
> <mailto:hf...@sp...>> wrote:
>
>     On Tue, 10 Jan 2023 13:32:52 -0800, Daniel Markstedt wrote:
>      > Aha, of course, they mustn't have been added to whatever "make dist"
>      > mechanism is used in this project.
>
>     I have patched out the #include for pkgsrc net/netatalk22 -- the
>     package has a dependency on openssl 1.1, so the 1.0 compatibility is
>     never used.
>
>     But the source tarball should be consistent.
>
>     Cheerio,
>     Hauke
>
>     --
>           The ASCII Ribbon Campaign                    Hauke Fath
>     ()     No HTML/RTF in email            Institut für Nachrichtentechnik
>     /\     No Word docs in email                     TU Darmstadt
>           Respect for open standards              Ruf +49-6151-16-21344
>
>
>
> _______________________________________________
> Netatalk-devel mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Ralph B. <sl...@sa...>]

Howdy!

This is still an open question. I'd favor the move as releasing via 
github is much less hassle and SF is a dead horse anyway.


Cheers!
-slow


On 1/11/23 15:35, Andrew Bauer wrote:
> I apologize if I missed it, but was the original question, asking 
> whether new releases have been moved to github, been answered?
> 
> I manage the netatalk packages for fedora and epel. Right now fedora and 
> epel branches are looking at sourceforge for new release notifications. 
> I can certainly change that, but I'd like to be certain before I do.
> 
> Thanks,
> Andy
> 
> No Trees were killed in the sending of this message.
> However, a large number of electrons were terribly inconvenienced.
> ------------------------------------------------------------------------
> *From:* Daniel Markstedt <mar...@gm...>
> *Sent:* Tuesday, January 10, 2023 4:23 PM
> *To:* Hauke Fath <hf...@sp...>
> *Cc:* net...@li... 
> <net...@li...>; Hauke Fath 
> <ha...@es...>
> *Subject:* Re: [Netatalk-devel] Moving Netatalk Releases to github?
> PR for getting rid of the OpenSSL 1.0 header here: 
> https://github.com/Netatalk/Netatalk/pull/183 
> <https://github.com/Netatalk/Netatalk/pull/183>
> 
> On Tue, Jan 10, 2023 at 1:35 PM Hauke Fath <hf...@sp... 
> <mailto:hf...@sp...>> wrote:
> 
>     On Tue, 10 Jan 2023 13:32:52 -0800, Daniel Markstedt wrote:
>      > Aha, of course, they mustn't have been added to whatever "make dist"
>      > mechanism is used in this project.
> 
>     I have patched out the #include for pkgsrc net/netatalk22 -- the
>     package has a dependency on openssl 1.1, so the 1.0 compatibility is
>     never used.
> 
>     But the source tarball should be consistent.
> 
>     Cheerio,
>     Hauke
> 
>     -- 
>           The ASCII Ribbon Campaign                    Hauke Fath
>     ()     No HTML/RTF in email            Institut für Nachrichtentechnik
>     /\     No Word docs in email                     TU Darmstadt
>           Respect for open standards              Ruf +49-6151-16-21344
> 
> 
> 
> _______________________________________________
> Netatalk-devel mailing list
> Net...@li...
> https://lists.sourceforge.net/lists/listinfo/netatalk-devel

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Andrew B. <kni...@ou...>]

I apologize if I missed it, but was the original question, asking whether new releases have been moved to github, been answered?

I manage the netatalk packages for fedora and epel. Right now fedora and epel branches are looking at sourceforge for new release notifications. I can certainly change that, but I'd like to be certain before I do.

Thanks,
Andy

No Trees were killed in the sending of this message.
However, a large number of electrons were terribly inconvenienced.
________________________________
From: Daniel Markstedt <mar...@gm...>
Sent: Tuesday, January 10, 2023 4:23 PM
To: Hauke Fath <hf...@sp...>
Cc: net...@li... <net...@li...>; Hauke Fath <ha...@es...>
Subject: Re: [Netatalk-devel] Moving Netatalk Releases to github?

PR for getting rid of the OpenSSL 1.0 header here: https://github.com/Netatalk/Netatalk/pull/183

On Tue, Jan 10, 2023 at 1:35 PM Hauke Fath <hf...@sp...<mailto:hf...@sp...>> wrote:
On Tue, 10 Jan 2023 13:32:52 -0800, Daniel Markstedt wrote:
> Aha, of course, they mustn't have been added to whatever "make dist"
> mechanism is used in this project.

I have patched out the #include for pkgsrc net/netatalk22 -- the
package has a dependency on openssl 1.1, so the 1.0 compatibility is
never used.

But the source tarball should be consistent.

Cheerio,
Hauke

--
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-21344

[Netatalk-devel] usubscribe

[Дмитрий Д. <do...@ng...>]

Здравствуйте, Netatalk-devel,




-- 
С уважением, 
    Дмитрий Долженко                  mailto:do...@ng...

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Daniel M. <mar...@gm...>]

PR for getting rid of the OpenSSL 1.0 header here:
https://github.com/Netatalk/Netatalk/pull/183

On Tue, Jan 10, 2023 at 1:35 PM Hauke Fath <hf...@sp...> wrote:

> On Tue, 10 Jan 2023 13:32:52 -0800, Daniel Markstedt wrote:
> > Aha, of course, they mustn't have been added to whatever "make dist"
> > mechanism is used in this project.
>
> I have patched out the #include for pkgsrc net/netatalk22 -- the
> package has a dependency on openssl 1.1, so the 1.0 compatibility is
> never used.
>
> But the source tarball should be consistent.
>
> Cheerio,
> Hauke
>
> --
>      The ASCII Ribbon Campaign                    Hauke Fath
> ()     No HTML/RTF in email            Institut für Nachrichtentechnik
> /\     No Word docs in email                     TU Darmstadt
>      Respect for open standards              Ruf +49-6151-16-21344
>

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Hauke F. <hf...@sp...>]

On Tue, 10 Jan 2023 13:32:52 -0800, Daniel Markstedt wrote:
> Aha, of course, they mustn't have been added to whatever "make dist"
> mechanism is used in this project.

I have patched out the #include for pkgsrc net/netatalk22 -- the 
package has a dependency on openssl 1.1, so the 1.0 compatibility is 
never used.

But the source tarball should be consistent.

Cheerio,
Hauke

-- 
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-21344

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Daniel M. <mar...@gm...>]

Hauke,

Aha, of course, they mustn't have been added to whatever "make dist"
mechanism is used in this project.

Ralph,

Thanks for preparing and announcing the releases! I'm very pleased and
excited to see new versions in the wild now.

I'm not a maintainer and don't have any investment in the SF distribution
channel.
Naturally, I am very supportive of moving the release distribution to
GitHub.

 Best,
Daniel

On Tue, Jan 10, 2023 at 1:07 PM Hauke Fath <hf...@sp...> wrote:

> On Tue, 10 Jan 2023 13:02:02 -0800, Daniel Markstedt wrote:
> > The openssl_compat code was introduced with
> >
>
> https://github.com/Netatalk/Netatalk/commit/53c10442cd4372c15cca9c13a30b4a1120df9179
>
> Ah, okay. The openssl_compat.{c,h} files are not in the 2.2.7 release
> tarball, though.
>
> Cheerio,
> Hauke
>
> --
>      The ASCII Ribbon Campaign                    Hauke Fath
> ()     No HTML/RTF in email            Institut für Nachrichtentechnik
> /\     No Word docs in email                     TU Darmstadt
>      Respect for open standards              Ruf +49-6151-16-21344
>

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Hauke F. <hf...@sp...>]

On Tue, 10 Jan 2023 13:02:02 -0800, Daniel Markstedt wrote:
> The openssl_compat code was introduced with
> 
https://github.com/Netatalk/Netatalk/commit/53c10442cd4372c15cca9c13a30b4a1120df9179

Ah, okay. The openssl_compat.{c,h} files are not in the 2.2.7 release 
tarball, though.

Cheerio,
Hauke

-- 
     The ASCII Ribbon Campaign                    Hauke Fath
()     No HTML/RTF in email            Institut für Nachrichtentechnik
/\     No Word docs in email                     TU Darmstadt
     Respect for open standards              Ruf +49-6151-16-21344

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Hauke F. <hauke@Espresso.Rhein-Neckar.DE>]

On Tue, 10 Jan 2023 10:59:04 +0100, Ralph Boehme via Netatalk-devel 
wrote:
>> Please check it out here:
>> 
>> https://github.com/Netatalk/Netatalk/releases/tag/netatalk-2-2-7

Thanks for the release engineering!

Build on netbsd-10 fails with

[...]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../.. 
-I/var/obj/pkgsrc/net/netatalk22/work/.buildlink/include 
-I/var/obj/pkgsrc/net/netatalk22/work/.buildlink/include/db4 
-I/usr/include/openssl -I../../sys/netbsd -I../../include 
"-D_U_=__attribute__((unused))" -O2 -g3 -fPIC -D_FORTIFY_SOURCE=2 
-I../../sys -MT uams_randnum.lo -MD -MP -MF .deps/uams_randnum.Tpo -c 
uams_randnum.c  -fPIC -DPIC -o .libs/uams_randnum.o
uams_dhx_passwd.c:40:10: fatal error: openssl_compat.h: No such file or 
directory
   40 | #include "openssl_compat.h"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
gmake[4]: *** [Makefile:773: uams_dhx_passwd.lo] Error 1

-- no "openssl_compat.h" anywhere in sight, and a web search is 
inconclusive. I guess autoconf needs to check for the header's 
presence, if it is needed at all?

[hauke@pizza] /<3>net/netatalk22 > openssl version
OpenSSL 1.1.1n  15 Mar 2022
[hauke@pizza] /<3>net/netatalk22 >

Cheerio,
Hauke

-- 
Hauke Fath                        <hauke@Espresso.Rhein-Neckar.DE>
Linnéweg 7
64342 Seeheim-Jugenheim
Germany

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Daniel M. <mar...@gm...>]

Thanks for testing, Hauke.

The openssl_compat code was introduced with
https://github.com/Netatalk/Netatalk/commit/53c10442cd4372c15cca9c13a30b4a1120df9179
Perhaps we can just revert this? I don't see a huge importance in
maintaining backwards compatibility with OpenSSL 1.0.
On the contrary, with the whole Heartbeat debacle it's probably safer to
*discourage* OpenSSL 1.0 usage.

Thoughts?


On Tue, Jan 10, 2023 at 12:51 PM Hauke Fath <ha...@es...>
wrote:

> On Tue, 10 Jan 2023 10:59:04 +0100, Ralph Boehme via Netatalk-devel
> wrote:
> >> Please check it out here:
> >>
> >> https://github.com/Netatalk/Netatalk/releases/tag/netatalk-2-2-7
>
> Thanks for the release engineering!
>
> Build on netbsd-10 fails with
>
> [...]
> libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I../..
> -I/var/obj/pkgsrc/net/netatalk22/work/.buildlink/include
> -I/var/obj/pkgsrc/net/netatalk22/work/.buildlink/include/db4
> -I/usr/include/openssl -I../../sys/netbsd -I../../include
> "-D_U_=__attribute__((unused))" -O2 -g3 -fPIC -D_FORTIFY_SOURCE=2
> -I../../sys -MT uams_randnum.lo -MD -MP -MF .deps/uams_randnum.Tpo -c
> uams_randnum.c  -fPIC -DPIC -o .libs/uams_randnum.o
> uams_dhx_passwd.c:40:10: fatal error: openssl_compat.h: No such file or
> directory
>    40 | #include "openssl_compat.h"
>       |          ^~~~~~~~~~~~~~~~~~
> compilation terminated.
> gmake[4]: *** [Makefile:773: uams_dhx_passwd.lo] Error 1
>
> -- no "openssl_compat.h" anywhere in sight, and a web search is
> inconclusive. I guess autoconf needs to check for the header's
> presence, if it is needed at all?
>
> [hauke@pizza] /<3>net/netatalk22 > openssl version
> OpenSSL 1.1.1n  15 Mar 2022
> [hauke@pizza] /<3>net/netatalk22 >
>
> Cheerio,
> Hauke
>
> --
> Hauke Fath                        <hauke@Espresso.Rhein-Neckar.DE>
> Linnéweg 7
> 64342 Seeheim-Jugenheim
> Germany
>

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Jeff H. <jef...@gm...>]

And my final note before I slunk away, someone has modified the zip of the
branch's source so that there are no diffs between it and the head of the
branch. Problem solve-ed.

If it weren't any fun, I'd say I wasted quite a bit of time on this.

On Tue, Jan 10, 2023 at 12:54 PM Jeff Holt <jef...@gm...> wrote:

> So sorry, everyone. I missed a couple of steps in the repro:
>
> Repro:
> cd $HOME
> mkdir test
> cd test
> unzip $HOME/Netatalk-branch-netatalk-3-1.zip (downloaded from github
> project website)
> git clone https://github.com/Netatalk/Netatalk.git
> cd Netatalk
> git checkout branch-netatalk-3-1
> cd ..
> diff -q -r Netatalk Netatalk-branch-netatalk-3-1 | wc -l
> 76
> diff Netatalk/libatalk/adouble/ad_attr.c
> Netatalk-branch-netatalk-3-1/libatalk/adouble/ad_attr.c|wc -l
> 173
>
>
> On Tue, Jan 10, 2023 at 12:43 PM Jeff Holt <jef...@gm...>
> wrote:
>
>> I'm confused. The source code zip file of branch-netatalk-3-1 that I
>> downloaded a couple of days ago has source that is VASTLY different than
>> what I see when I clone the repo and then checkout branch-netatalk-3-1.
>>
>> Repro:
>> cd $HOME
>> mkdir test
>> cd test
>> unzip $HOME/Netatalk-branch-netatalk-3-1.zip (downloaded from github
>> project website)
>> git clone https://github.com/Netatalk/Netatalk.git
>> diff -q -r Netatalk Netatalk-branch-netatalk-3-1 | wc -l
>> 81
>> diff Netatalk/libatalk/adouble/ad_attr.c
>> Netatalk-branch-netatalk-3-1/libatalk/adouble/ad_attr.c|wc -l
>> 173
>>
>> Can anyone explain this inconsistency?
>>
>> When I look at the diff of ad_attr.c, I see someone has indeed made
>> assertions that address the problem. In fact, all I have to do is fix the
>> my_bool=>bool problem. Then bootstrap, configure, make, and make install.
>> The branch's code works just fine.
>>
>> The problem is the github project web site gave me the wrong zip file
>> when I asked it for the zip'd source for the 3-1 branch.
>>
>> Why is that?
>>
>>
>> On Tue, Jan 10, 2023 at 11:44 AM Jeff Holt <jef...@gm...>
>> wrote:
>>
>>> I'm not a github aficionado but git's my guy. I'll do upon your
>>> encouragement.
>>>
>>> On Tue, Jan 10, 2023 at 11:26 AM Daniel Markstedt <mar...@gm...>
>>> wrote:
>>>
>>>> Hi Jeff,
>>>>
>>>> It's great to see the deep dive in the codebase! I'm not surprised that
>>>> there are unprotected calls here and there.
>>>> Would you be able to submit this as a PR in Github? I might be spoiled,
>>>> but I find it much easier to read a patchset in PR form.
>>>>
>>>> -> https://github.com/Netatalk/Netatalk
>>>>
>>>> On Mon, Jan 9, 2023 at 5:51 PM Jeff Holt <jef...@gm...>
>>>> wrote:
>>>>
>>>>> I think I have something partially working. Unified diffs and the
>>>>> changed files are attached. My theme for the changes is this:
>>>>>
>>>>> If ad_entry returns NULL, then its caller will issue a warning instead
>>>>>> of executing a memcpy that would raise SIGSEGV.
>>>>>
>>>>>
>>>>> I don't know if my changes are reasonable but it's behaving infinitely
>>>>> better than it was. I also don't know if the problem is inside ad_entry or
>>>>> if it's a problem with the callers (as I've assumed).
>>>>>
>>>>> I can do all the following on the remote mount:
>>>>> - read a file
>>>>> - write a file
>>>>> - remove a file
>>>>> - change the permission of a file
>>>>>
>>>>> I am highly motivated to fix this problem considering how much faster
>>>>> afp is compared to smb. It's like a race between Carl Lewis and Jerry Lewis.
>>>>>
>>>>> PS I kept the unified diffs separate because I suspect one of the
>>>>> differences needs to be ignored (mysql related boolean datatype).
>>>>>
>>>>> afp.zip contains all the files I changed in branch-netatalk-3-1 as of
>>>>> commit 15687531633e2444d3a6fbe64f86800a159d45cc
>>>>> afp_unif.zip contains the unified diffs for each of the four files
>>>>> that I changed
>>>>>
>>>>> On Mon, Jan 9, 2023 at 1:16 PM Jeff Holt <jef...@gm...>
>>>>> wrote:
>>>>>
>>>>>> There is at least one problem in ad_open.c, possibly two. The
>>>>>> immediate problem is a broken contract in ad_open.c between new_ad_header
>>>>>> and ad_entry.
>>>>>>
>>>>>> ad_entry can return null but new_ad_header assumes ad_entry cannot
>>>>>> return null. Therefore, on line 370, it adds FINDERINFO_FRTYPEOFF (9) to 0
>>>>>> and then calls memcpy with a destination address of 9, which causes the
>>>>>> segmentation violation.
>>>>>>
>>>>>> I found about 15 files or so that have code that calls ad_entry,
>>>>>> nearly all of them unprotected calls. Here are the some of the callers that
>>>>>> ARE protected against ad_entry returning NULL:
>>>>>>
>>>>>> ad_open.c: ad_header_read_ea
>>>>>> ad_set.c: change_creator
>>>>>> uniconv.c: check_adouble
>>>>>> file.c: get_finderinfo
>>>>>>
>>>>>> When I modify new_ad_header to return 0 early, when ad_entry returns
>>>>>> NULL, then I get a different (i.e., downstream) segmentation violation
>>>>>> backtrace that lays blame on line 23 (in ad_setdate) in file ad_date.c.
>>>>>>
>>>>>> Considering how many places in the code have unprotected calls to
>>>>>> ad_entry, this situation is not looking good.
>>>>>>
>>>>>> I'm now wondering if someone failed to merge some or all of a commit
>>>>>> into the master and this particular branch.
>>>>>>
>>>>>> On Mon, Jan 9, 2023 at 10:24 AM Jeff Holt <jef...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you, everyone, for your responses. Nice community.
>>>>>>>
>>>>>>> I just built from branch branch-netatalk-3-1 and got the same
>>>>>>> backtrace in afpd.log.
>>>>>>>
>>>>>>> To be fully transparent, this is what I did just now:
>>>>>>>
>>>>>>> bootstrap
>>>>>>> export CFLAGS=-g
>>>>>>> configure --enable-debug --enable-debugging
>>>>>>> make clean
>>>>>>> make
>>>>>>> # wrt comment 9 of bug 692560, change my_bool to bool in cnid_mysql.c
>>>>>>> vi ./libatalk/cnid/mysql/cnid_mysql.c
>>>>>>> make
>>>>>>> make install
>>>>>>> netatalk
>>>>>>> ps -ef | grep afpd # this shows one process
>>>>>>> gdb -p parent-pid /usr/local/sbin/afpd
>>>>>>>
>>>>>>> I set detach-on-fork to off, set a breakpoint in netatalk_panic, and
>>>>>>> then continued execution.
>>>>>>>
>>>>>>> But Finder wouldn't present the list of volumes after connecting.
>>>>>>> So, I interrupted and tried continuing after the volume dialog was
>>>>>>> presented.
>>>>>>>
>>>>>>> But it never broke.
>>>>>>>
>>>>>>> I believe it's because I made gdb attach to the parent. So I tried
>>>>>>> connecting one more time. After it presented the list of volumes, I looked
>>>>>>> at the processes again
>>>>>>>
>>>>>>> ps -ef | grep afpd # this shows a parent and a child
>>>>>>>
>>>>>>> I assumed the child-pid was the one that had given the list of
>>>>>>> volumes to Finder.
>>>>>>>
>>>>>>> gdb -p child-pid /usr/local/sbin/afpd
>>>>>>>
>>>>>>> I probably did not need to set detach-on-fork to off but I did
>>>>>>> anyway, set the breakpoint in netatalk_panic and then continued.
>>>>>>>
>>>>>>> When I clicked [OK] in Finder, gdb stopped in netatalk_panic and it
>>>>>>> printed this when I executed the bt command:
>>>>>>>
>>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>>> __memmove_avx_unaligned_erms () at
>>>>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>>>>> Download failed: Function not implemented.  Continuing without
>>>>>>> source file
>>>>>>> ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S.
>>>>>>> 328 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No
>>>>>>> such file or directory.
>>>>>>> (gdb) bt
>>>>>>> #0  __memmove_avx_unaligned_erms () at
>>>>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>>>>> #1  0x00007f359dd03bc6 in new_ad_header (ad=0x7fff0002aa30,
>>>>>>> path=0x5555e82f3730 "/u00/family", stp=0x0, adflags=1292) at ad_open.c:370
>>>>>>> #2  0x00007f359dd06bb4 in ad_open_hf_ea (path=0x5555e82f3730
>>>>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1251
>>>>>>> #3  0x00007f359dd06e7a in ad_open_hf (path=0x5555e82f3730
>>>>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1288
>>>>>>> #4  0x00007f359dd08c67 in ad_open (ad=0x7fff0002aa30,
>>>>>>> path=0x5555e82f3730 "/u00/family", adflags=1292) at ad_open.c:1998
>>>>>>> #5  0x00005555e7fc0790 in getvolparams
>>>>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>>>>> st=0x7fff0002b0b0, buf=0x5555e8313d82 "\372\200\002", buflen=0x7fff0002b0a8)
>>>>>>>     at volume.c:319
>>>>>>> #6  0x00005555e7fc10bc in stat_vol
>>>>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>>>>> rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80) at
>>>>>>> volume.c:521
>>>>>>> #7  0x00005555e7fc21c1 in afp_openvol
>>>>>>>     (obj=0x5555e7fef960 <obj>, ibuf=0x7f359b43801c
>>>>>>> "\333\374Pz\325\062m`", ibuflen=12, rbuf=0x5555e8313d80 "+N\372\200\002",
>>>>>>> rbuflen=0x5555e8323d80)
>>>>>>>     at volume.c:848
>>>>>>> #8  0x00005555e7f9019f in afp_over_dsi (obj=0x5555e7fef960 <obj>) at
>>>>>>> afp_dsi.c:627
>>>>>>> #9  0x00005555e7fb6a4c in dsi_start (obj=0x5555e7fef960 <obj>,
>>>>>>> dsi=0x5555e8313690, server_children=0x5555e830fa20) at main.c:474
>>>>>>> #10 0x00005555e7fb6750 in main (ac=4, av=0x7fff0002b5b8) at
>>>>>>> main.c:417
>>>>>>>
>>>>>>> Since everyone was so nice helping me, I will look more closely at
>>>>>>> the call stack to see if there's anything I can do to fix this. But please
>>>>>>> feel free to stop me if you think you know what's going one.
>>>>>>>
>>>>>>> Warm regards.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Sun, Jan 8, 2023 at 3:44 PM Daniel Markstedt <mar...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Jeff,
>>>>>>>>
>>>>>>>> In my experience the challenge with debugging afpd in gdb is to
>>>>>>>> follow the forked processes.
>>>>>>>> Start out with "set detach-on-fork off", launch the process, note
>>>>>>>> the pid that is created, then attach to that pid.
>>>>>>>> This *should* get you to a state where you can capture the stack
>>>>>>>> trace.
>>>>>>>>
>>>>>>>> Note that my experience is mostly with Netatalk 2.2 so your mileage
>>>>>>>> may vary.
>>>>>>>>
>>>>>>>> BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical
>>>>>>>> bug fix is in that branch that's not yet in any stable release.
>>>>>>>>
>>>>>>>> Best,
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>> On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> TLDR; How can I start netatalk or afpd in gdb so that I can get a
>>>>>>>>> complete stack trace when a signal is raised? I tried setting a breakpoint
>>>>>>>>> in netatalk_panic but it's not working.
>>>>>>>>>
>>>>>>>>> Quite a few years ago, I had a version of netatalk running on my
>>>>>>>>> ubuntu server. Then due to some compatibility problems, I could no longer
>>>>>>>>> use it. I tried upgrading to Ubuntu 21.04 but that didn't help. So I
>>>>>>>>> switched to samba.
>>>>>>>>>
>>>>>>>>> Today I noticed netatalk 3.1.13 is newer than the version I last
>>>>>>>>> tried.
>>>>>>>>>
>>>>>>>>> I compiled and installed libevent-2.1.12-stable.tar.gz and
>>>>>>>>> netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after
>>>>>>>>> unmasking), I started the server with this:
>>>>>>>>>      $ netatalk
>>>>>>>>>
>>>>>>>>> Then I tried to "Connect to Server..." to the server using the afp
>>>>>>>>> protocol instead of the smb protocol. Finder raised the volume selection
>>>>>>>>> dialog and I chose the volume I wanted to access and clicked [OK]. I
>>>>>>>>> immediately saw an error dialog.
>>>>>>>>>
>>>>>>>>> Then I looked at /var/log/afpd.log and saw this:
>>>>>>>>>
>>>>>>>>> Jan 07 17:38:17.584432 afpd[266029] {fault.c:123}
>>>>>>>>> (severe:Default):
>>>>>>>>> ===============================================================
>>>>>>>>> Jan 07 17:38:17.584524 afpd[266029] {fault.c:124}
>>>>>>>>> (severe:Default): INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
>>>>>>>>> Jan 07 17:38:17.584554 afpd[266029] {fault.c:125}
>>>>>>>>> (severe:Default):
>>>>>>>>> ===============================================================
>>>>>>>>> Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default):
>>>>>>>>> PANIC: internal error
>>>>>>>>> Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default):
>>>>>>>>> BACKTRACE: 17 stack frames:
>>>>>>>>> Jan 07 17:38:17.585291 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #0 /usr/local/lib/libatalk.so.18(netatalk_panic+0x39)
>>>>>>>>> [0x7f42b719338f]
>>>>>>>>> Jan 07 17:38:17.585315 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #1 /usr/local/lib/libatalk.so.18(+0x485f9)
>>>>>>>>> [0x7f42b71935f9]
>>>>>>>>> Jan 07 17:38:17.585338 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #2 /usr/local/lib/libatalk.so.18(+0x48653)
>>>>>>>>> [0x7f42b7193653]
>>>>>>>>> Jan 07 17:38:17.585361 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #3 /lib/x86_64-linux-gnu/libc.so.6(+0x41040)
>>>>>>>>> [0x7f42b6f6b040]
>>>>>>>>> Jan 07 17:38:17.585384 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #4 /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1)
>>>>>>>>> [0x7f42b70acff1]
>>>>>>>>> Jan 07 17:38:17.585409 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #5 /usr/local/lib/libatalk.so.18(+0x1cbc6)
>>>>>>>>> [0x7f42b7167bc6]
>>>>>>>>> Jan 07 17:38:17.585432 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #6 /usr/local/lib/libatalk.so.18(+0x1fbb4)
>>>>>>>>> [0x7f42b716abb4]
>>>>>>>>> Jan 07 17:38:17.585459 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #7 /usr/local/lib/libatalk.so.18(+0x1fe7a)
>>>>>>>>> [0x7f42b716ae7a]
>>>>>>>>> Jan 07 17:38:17.585482 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #8 /usr/local/lib/libatalk.so.18(ad_open+0x3f8)
>>>>>>>>> [0x7f42b716cc67]
>>>>>>>>> Jan 07 17:38:17.585505 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #9 /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
>>>>>>>>> Jan 07 17:38:17.585528 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #10 /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
>>>>>>>>> Jan 07 17:38:17.585551 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #11 /usr/local/sbin/afpd(afp_openvol+0x7e0)
>>>>>>>>> [0x55e2950971c1]
>>>>>>>>> Jan 07 17:38:17.585574 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #12 /usr/local/sbin/afpd(afp_over_dsi+0x807)
>>>>>>>>> [0x55e29506519f]
>>>>>>>>> Jan 07 17:38:17.585598 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #13 /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
>>>>>>>>> Jan 07 17:38:17.585620 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #14 /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
>>>>>>>>> Jan 07 17:38:17.585644 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #15
>>>>>>>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5) [0x7f42b6f52565]
>>>>>>>>> Jan 07 17:38:17.585667 afpd[266029] {fault.c:103}
>>>>>>>>> (severe:Default):  #16 /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]
>>>>>>>>>
>>>>>>>>> Since I'm not a maintainer of this code, this doesn't help me very
>>>>>>>>> much. At first I thought I needed to compile in debug mode. So, I set
>>>>>>>>> CFLAGS=-g and configured configured libevent2 and netatalk for debugging:
>>>>>>>>>
>>>>>>>>> $ cd ../libevent-2.1.12-stable
>>>>>>>>> $ ./configure --enable-verbose-debug
>>>>>>>>> $ make clean
>>>>>>>>> $ make
>>>>>>>>> $ make install
>>>>>>>>> $ cd ../netatalk-3.1.13
>>>>>>>>> $ ./configure --enable-debug --enable-debugging
>>>>>>>>> $ make clean
>>>>>>>>> $ make
>>>>>>>>> $ make install
>>>>>>>>>
>>>>>>>>> Then I use the file command to make sure it would emit "with
>>>>>>>>> debug_info, not stripped" for the files mentioned in the above backtrace.
>>>>>>>>> Then I tried the test again. Same thing.
>>>>>>>>>
>>>>>>>>> I've written signal handlers and know that emitting line numbers
>>>>>>>>> in the call stack is non-trivial so I now believe the only way to get that
>>>>>>>>> information is to run the code in gdb and let its bt command show me what I
>>>>>>>>> need.
>>>>>>>>>
>>>>>>>>> So, how do I start the code so I can get a backtrace? I've tried
>>>>>>>>> and it's not working.
>>>>>>>>>
>>>>>>>>> Thank you.
>>>>>>>>> _______________________________________________
>>>>>>>>> Netatalk-devel mailing list
>>>>>>>>> Net...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>>>>>>>>
>>>>>>>>

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Jeff H. <jef...@gm...>]

So sorry, everyone. I missed a couple of steps in the repro:

Repro:
cd $HOME
mkdir test
cd test
unzip $HOME/Netatalk-branch-netatalk-3-1.zip (downloaded from github
project website)
git clone https://github.com/Netatalk/Netatalk.git
cd Netatalk
git checkout branch-netatalk-3-1
cd ..
diff -q -r Netatalk Netatalk-branch-netatalk-3-1 | wc -l
76
diff Netatalk/libatalk/adouble/ad_attr.c
Netatalk-branch-netatalk-3-1/libatalk/adouble/ad_attr.c|wc -l
173


On Tue, Jan 10, 2023 at 12:43 PM Jeff Holt <jef...@gm...> wrote:

> I'm confused. The source code zip file of branch-netatalk-3-1 that I
> downloaded a couple of days ago has source that is VASTLY different than
> what I see when I clone the repo and then checkout branch-netatalk-3-1.
>
> Repro:
> cd $HOME
> mkdir test
> cd test
> unzip $HOME/Netatalk-branch-netatalk-3-1.zip (downloaded from github
> project website)
> git clone https://github.com/Netatalk/Netatalk.git
> diff -q -r Netatalk Netatalk-branch-netatalk-3-1 | wc -l
> 81
> diff Netatalk/libatalk/adouble/ad_attr.c
> Netatalk-branch-netatalk-3-1/libatalk/adouble/ad_attr.c|wc -l
> 173
>
> Can anyone explain this inconsistency?
>
> When I look at the diff of ad_attr.c, I see someone has indeed made
> assertions that address the problem. In fact, all I have to do is fix the
> my_bool=>bool problem. Then bootstrap, configure, make, and make install.
> The branch's code works just fine.
>
> The problem is the github project web site gave me the wrong zip file when
> I asked it for the zip'd source for the 3-1 branch.
>
> Why is that?
>
>
> On Tue, Jan 10, 2023 at 11:44 AM Jeff Holt <jef...@gm...>
> wrote:
>
>> I'm not a github aficionado but git's my guy. I'll do upon your
>> encouragement.
>>
>> On Tue, Jan 10, 2023 at 11:26 AM Daniel Markstedt <mar...@gm...>
>> wrote:
>>
>>> Hi Jeff,
>>>
>>> It's great to see the deep dive in the codebase! I'm not surprised that
>>> there are unprotected calls here and there.
>>> Would you be able to submit this as a PR in Github? I might be spoiled,
>>> but I find it much easier to read a patchset in PR form.
>>>
>>> -> https://github.com/Netatalk/Netatalk
>>>
>>> On Mon, Jan 9, 2023 at 5:51 PM Jeff Holt <jef...@gm...>
>>> wrote:
>>>
>>>> I think I have something partially working. Unified diffs and the
>>>> changed files are attached. My theme for the changes is this:
>>>>
>>>> If ad_entry returns NULL, then its caller will issue a warning instead
>>>>> of executing a memcpy that would raise SIGSEGV.
>>>>
>>>>
>>>> I don't know if my changes are reasonable but it's behaving infinitely
>>>> better than it was. I also don't know if the problem is inside ad_entry or
>>>> if it's a problem with the callers (as I've assumed).
>>>>
>>>> I can do all the following on the remote mount:
>>>> - read a file
>>>> - write a file
>>>> - remove a file
>>>> - change the permission of a file
>>>>
>>>> I am highly motivated to fix this problem considering how much faster
>>>> afp is compared to smb. It's like a race between Carl Lewis and Jerry Lewis.
>>>>
>>>> PS I kept the unified diffs separate because I suspect one of the
>>>> differences needs to be ignored (mysql related boolean datatype).
>>>>
>>>> afp.zip contains all the files I changed in branch-netatalk-3-1 as of
>>>> commit 15687531633e2444d3a6fbe64f86800a159d45cc
>>>> afp_unif.zip contains the unified diffs for each of the four files that
>>>> I changed
>>>>
>>>> On Mon, Jan 9, 2023 at 1:16 PM Jeff Holt <jef...@gm...>
>>>> wrote:
>>>>
>>>>> There is at least one problem in ad_open.c, possibly two. The
>>>>> immediate problem is a broken contract in ad_open.c between new_ad_header
>>>>> and ad_entry.
>>>>>
>>>>> ad_entry can return null but new_ad_header assumes ad_entry cannot
>>>>> return null. Therefore, on line 370, it adds FINDERINFO_FRTYPEOFF (9) to 0
>>>>> and then calls memcpy with a destination address of 9, which causes the
>>>>> segmentation violation.
>>>>>
>>>>> I found about 15 files or so that have code that calls ad_entry,
>>>>> nearly all of them unprotected calls. Here are the some of the callers that
>>>>> ARE protected against ad_entry returning NULL:
>>>>>
>>>>> ad_open.c: ad_header_read_ea
>>>>> ad_set.c: change_creator
>>>>> uniconv.c: check_adouble
>>>>> file.c: get_finderinfo
>>>>>
>>>>> When I modify new_ad_header to return 0 early, when ad_entry returns
>>>>> NULL, then I get a different (i.e., downstream) segmentation violation
>>>>> backtrace that lays blame on line 23 (in ad_setdate) in file ad_date.c.
>>>>>
>>>>> Considering how many places in the code have unprotected calls to
>>>>> ad_entry, this situation is not looking good.
>>>>>
>>>>> I'm now wondering if someone failed to merge some or all of a commit
>>>>> into the master and this particular branch.
>>>>>
>>>>> On Mon, Jan 9, 2023 at 10:24 AM Jeff Holt <jef...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Thank you, everyone, for your responses. Nice community.
>>>>>>
>>>>>> I just built from branch branch-netatalk-3-1 and got the same
>>>>>> backtrace in afpd.log.
>>>>>>
>>>>>> To be fully transparent, this is what I did just now:
>>>>>>
>>>>>> bootstrap
>>>>>> export CFLAGS=-g
>>>>>> configure --enable-debug --enable-debugging
>>>>>> make clean
>>>>>> make
>>>>>> # wrt comment 9 of bug 692560, change my_bool to bool in cnid_mysql.c
>>>>>> vi ./libatalk/cnid/mysql/cnid_mysql.c
>>>>>> make
>>>>>> make install
>>>>>> netatalk
>>>>>> ps -ef | grep afpd # this shows one process
>>>>>> gdb -p parent-pid /usr/local/sbin/afpd
>>>>>>
>>>>>> I set detach-on-fork to off, set a breakpoint in netatalk_panic, and
>>>>>> then continued execution.
>>>>>>
>>>>>> But Finder wouldn't present the list of volumes after connecting. So,
>>>>>> I interrupted and tried continuing after the volume dialog was presented.
>>>>>>
>>>>>> But it never broke.
>>>>>>
>>>>>> I believe it's because I made gdb attach to the parent. So I tried
>>>>>> connecting one more time. After it presented the list of volumes, I looked
>>>>>> at the processes again
>>>>>>
>>>>>> ps -ef | grep afpd # this shows a parent and a child
>>>>>>
>>>>>> I assumed the child-pid was the one that had given the list of
>>>>>> volumes to Finder.
>>>>>>
>>>>>> gdb -p child-pid /usr/local/sbin/afpd
>>>>>>
>>>>>> I probably did not need to set detach-on-fork to off but I did
>>>>>> anyway, set the breakpoint in netatalk_panic and then continued.
>>>>>>
>>>>>> When I clicked [OK] in Finder, gdb stopped in netatalk_panic and it
>>>>>> printed this when I executed the bt command:
>>>>>>
>>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>>> __memmove_avx_unaligned_erms () at
>>>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>>>> Download failed: Function not implemented.  Continuing without source
>>>>>> file ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S.
>>>>>> 328 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such
>>>>>> file or directory.
>>>>>> (gdb) bt
>>>>>> #0  __memmove_avx_unaligned_erms () at
>>>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>>>> #1  0x00007f359dd03bc6 in new_ad_header (ad=0x7fff0002aa30,
>>>>>> path=0x5555e82f3730 "/u00/family", stp=0x0, adflags=1292) at ad_open.c:370
>>>>>> #2  0x00007f359dd06bb4 in ad_open_hf_ea (path=0x5555e82f3730
>>>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1251
>>>>>> #3  0x00007f359dd06e7a in ad_open_hf (path=0x5555e82f3730
>>>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1288
>>>>>> #4  0x00007f359dd08c67 in ad_open (ad=0x7fff0002aa30,
>>>>>> path=0x5555e82f3730 "/u00/family", adflags=1292) at ad_open.c:1998
>>>>>> #5  0x00005555e7fc0790 in getvolparams
>>>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>>>> st=0x7fff0002b0b0, buf=0x5555e8313d82 "\372\200\002", buflen=0x7fff0002b0a8)
>>>>>>     at volume.c:319
>>>>>> #6  0x00005555e7fc10bc in stat_vol
>>>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>>>> rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80) at
>>>>>> volume.c:521
>>>>>> #7  0x00005555e7fc21c1 in afp_openvol
>>>>>>     (obj=0x5555e7fef960 <obj>, ibuf=0x7f359b43801c
>>>>>> "\333\374Pz\325\062m`", ibuflen=12, rbuf=0x5555e8313d80 "+N\372\200\002",
>>>>>> rbuflen=0x5555e8323d80)
>>>>>>     at volume.c:848
>>>>>> #8  0x00005555e7f9019f in afp_over_dsi (obj=0x5555e7fef960 <obj>) at
>>>>>> afp_dsi.c:627
>>>>>> #9  0x00005555e7fb6a4c in dsi_start (obj=0x5555e7fef960 <obj>,
>>>>>> dsi=0x5555e8313690, server_children=0x5555e830fa20) at main.c:474
>>>>>> #10 0x00005555e7fb6750 in main (ac=4, av=0x7fff0002b5b8) at main.c:417
>>>>>>
>>>>>> Since everyone was so nice helping me, I will look more closely at
>>>>>> the call stack to see if there's anything I can do to fix this. But please
>>>>>> feel free to stop me if you think you know what's going one.
>>>>>>
>>>>>> Warm regards.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Jan 8, 2023 at 3:44 PM Daniel Markstedt <mar...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> Hi Jeff,
>>>>>>>
>>>>>>> In my experience the challenge with debugging afpd in gdb is to
>>>>>>> follow the forked processes.
>>>>>>> Start out with "set detach-on-fork off", launch the process, note
>>>>>>> the pid that is created, then attach to that pid.
>>>>>>> This *should* get you to a state where you can capture the stack
>>>>>>> trace.
>>>>>>>
>>>>>>> Note that my experience is mostly with Netatalk 2.2 so your mileage
>>>>>>> may vary.
>>>>>>>
>>>>>>> BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical
>>>>>>> bug fix is in that branch that's not yet in any stable release.
>>>>>>>
>>>>>>> Best,
>>>>>>> Daniel
>>>>>>>
>>>>>>> On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> TLDR; How can I start netatalk or afpd in gdb so that I can get a
>>>>>>>> complete stack trace when a signal is raised? I tried setting a breakpoint
>>>>>>>> in netatalk_panic but it's not working.
>>>>>>>>
>>>>>>>> Quite a few years ago, I had a version of netatalk running on my
>>>>>>>> ubuntu server. Then due to some compatibility problems, I could no longer
>>>>>>>> use it. I tried upgrading to Ubuntu 21.04 but that didn't help. So I
>>>>>>>> switched to samba.
>>>>>>>>
>>>>>>>> Today I noticed netatalk 3.1.13 is newer than the version I last
>>>>>>>> tried.
>>>>>>>>
>>>>>>>> I compiled and installed libevent-2.1.12-stable.tar.gz and
>>>>>>>> netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after
>>>>>>>> unmasking), I started the server with this:
>>>>>>>>      $ netatalk
>>>>>>>>
>>>>>>>> Then I tried to "Connect to Server..." to the server using the afp
>>>>>>>> protocol instead of the smb protocol. Finder raised the volume selection
>>>>>>>> dialog and I chose the volume I wanted to access and clicked [OK]. I
>>>>>>>> immediately saw an error dialog.
>>>>>>>>
>>>>>>>> Then I looked at /var/log/afpd.log and saw this:
>>>>>>>>
>>>>>>>> Jan 07 17:38:17.584432 afpd[266029] {fault.c:123} (severe:Default):
>>>>>>>> ===============================================================
>>>>>>>> Jan 07 17:38:17.584524 afpd[266029] {fault.c:124} (severe:Default):
>>>>>>>> INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
>>>>>>>> Jan 07 17:38:17.584554 afpd[266029] {fault.c:125} (severe:Default):
>>>>>>>> ===============================================================
>>>>>>>> Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default):
>>>>>>>> PANIC: internal error
>>>>>>>> Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default):
>>>>>>>> BACKTRACE: 17 stack frames:
>>>>>>>> Jan 07 17:38:17.585291 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #0 /usr/local/lib/libatalk.so.18(netatalk_panic+0x39) [0x7f42b719338f]
>>>>>>>> Jan 07 17:38:17.585315 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #1 /usr/local/lib/libatalk.so.18(+0x485f9) [0x7f42b71935f9]
>>>>>>>> Jan 07 17:38:17.585338 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #2 /usr/local/lib/libatalk.so.18(+0x48653) [0x7f42b7193653]
>>>>>>>> Jan 07 17:38:17.585361 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #3 /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f42b6f6b040]
>>>>>>>> Jan 07 17:38:17.585384 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #4 /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1) [0x7f42b70acff1]
>>>>>>>> Jan 07 17:38:17.585409 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #5 /usr/local/lib/libatalk.so.18(+0x1cbc6) [0x7f42b7167bc6]
>>>>>>>> Jan 07 17:38:17.585432 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #6 /usr/local/lib/libatalk.so.18(+0x1fbb4) [0x7f42b716abb4]
>>>>>>>> Jan 07 17:38:17.585459 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #7 /usr/local/lib/libatalk.so.18(+0x1fe7a) [0x7f42b716ae7a]
>>>>>>>> Jan 07 17:38:17.585482 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #8 /usr/local/lib/libatalk.so.18(ad_open+0x3f8) [0x7f42b716cc67]
>>>>>>>> Jan 07 17:38:17.585505 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #9 /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
>>>>>>>> Jan 07 17:38:17.585528 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #10 /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
>>>>>>>> Jan 07 17:38:17.585551 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #11 /usr/local/sbin/afpd(afp_openvol+0x7e0) [0x55e2950971c1]
>>>>>>>> Jan 07 17:38:17.585574 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #12 /usr/local/sbin/afpd(afp_over_dsi+0x807) [0x55e29506519f]
>>>>>>>> Jan 07 17:38:17.585598 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #13 /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
>>>>>>>> Jan 07 17:38:17.585620 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #14 /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
>>>>>>>> Jan 07 17:38:17.585644 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #15 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5)
>>>>>>>> [0x7f42b6f52565]
>>>>>>>> Jan 07 17:38:17.585667 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>>  #16 /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]
>>>>>>>>
>>>>>>>> Since I'm not a maintainer of this code, this doesn't help me very
>>>>>>>> much. At first I thought I needed to compile in debug mode. So, I set
>>>>>>>> CFLAGS=-g and configured configured libevent2 and netatalk for debugging:
>>>>>>>>
>>>>>>>> $ cd ../libevent-2.1.12-stable
>>>>>>>> $ ./configure --enable-verbose-debug
>>>>>>>> $ make clean
>>>>>>>> $ make
>>>>>>>> $ make install
>>>>>>>> $ cd ../netatalk-3.1.13
>>>>>>>> $ ./configure --enable-debug --enable-debugging
>>>>>>>> $ make clean
>>>>>>>> $ make
>>>>>>>> $ make install
>>>>>>>>
>>>>>>>> Then I use the file command to make sure it would emit "with
>>>>>>>> debug_info, not stripped" for the files mentioned in the above backtrace.
>>>>>>>> Then I tried the test again. Same thing.
>>>>>>>>
>>>>>>>> I've written signal handlers and know that emitting line numbers in
>>>>>>>> the call stack is non-trivial so I now believe the only way to get that
>>>>>>>> information is to run the code in gdb and let its bt command show me what I
>>>>>>>> need.
>>>>>>>>
>>>>>>>> So, how do I start the code so I can get a backtrace? I've tried
>>>>>>>> and it's not working.
>>>>>>>>
>>>>>>>> Thank you.
>>>>>>>> _______________________________________________
>>>>>>>> Netatalk-devel mailing list
>>>>>>>> Net...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>>>>>>>
>>>>>>>

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Jeff H. <jef...@gm...>]

I'm confused. The source code zip file of branch-netatalk-3-1 that I
downloaded a couple of days ago has source that is VASTLY different than
what I see when I clone the repo and then checkout branch-netatalk-3-1.

Repro:
cd $HOME
mkdir test
cd test
unzip $HOME/Netatalk-branch-netatalk-3-1.zip (downloaded from github
project website)
git clone https://github.com/Netatalk/Netatalk.git
diff -q -r Netatalk Netatalk-branch-netatalk-3-1 | wc -l
81
diff Netatalk/libatalk/adouble/ad_attr.c
Netatalk-branch-netatalk-3-1/libatalk/adouble/ad_attr.c|wc -l
173

Can anyone explain this inconsistency?

When I look at the diff of ad_attr.c, I see someone has indeed made
assertions that address the problem. In fact, all I have to do is fix the
my_bool=>bool problem. Then bootstrap, configure, make, and make install.
The branch's code works just fine.

The problem is the github project web site gave me the wrong zip file when
I asked it for the zip'd source for the 3-1 branch.

Why is that?


On Tue, Jan 10, 2023 at 11:44 AM Jeff Holt <jef...@gm...> wrote:

> I'm not a github aficionado but git's my guy. I'll do upon your
> encouragement.
>
> On Tue, Jan 10, 2023 at 11:26 AM Daniel Markstedt <mar...@gm...>
> wrote:
>
>> Hi Jeff,
>>
>> It's great to see the deep dive in the codebase! I'm not surprised that
>> there are unprotected calls here and there.
>> Would you be able to submit this as a PR in Github? I might be spoiled,
>> but I find it much easier to read a patchset in PR form.
>>
>> -> https://github.com/Netatalk/Netatalk
>>
>> On Mon, Jan 9, 2023 at 5:51 PM Jeff Holt <jef...@gm...>
>> wrote:
>>
>>> I think I have something partially working. Unified diffs and the
>>> changed files are attached. My theme for the changes is this:
>>>
>>> If ad_entry returns NULL, then its caller will issue a warning instead
>>>> of executing a memcpy that would raise SIGSEGV.
>>>
>>>
>>> I don't know if my changes are reasonable but it's behaving infinitely
>>> better than it was. I also don't know if the problem is inside ad_entry or
>>> if it's a problem with the callers (as I've assumed).
>>>
>>> I can do all the following on the remote mount:
>>> - read a file
>>> - write a file
>>> - remove a file
>>> - change the permission of a file
>>>
>>> I am highly motivated to fix this problem considering how much faster
>>> afp is compared to smb. It's like a race between Carl Lewis and Jerry Lewis.
>>>
>>> PS I kept the unified diffs separate because I suspect one of the
>>> differences needs to be ignored (mysql related boolean datatype).
>>>
>>> afp.zip contains all the files I changed in branch-netatalk-3-1 as of
>>> commit 15687531633e2444d3a6fbe64f86800a159d45cc
>>> afp_unif.zip contains the unified diffs for each of the four files that
>>> I changed
>>>
>>> On Mon, Jan 9, 2023 at 1:16 PM Jeff Holt <jef...@gm...>
>>> wrote:
>>>
>>>> There is at least one problem in ad_open.c, possibly two. The immediate
>>>> problem is a broken contract in ad_open.c between new_ad_header and
>>>> ad_entry.
>>>>
>>>> ad_entry can return null but new_ad_header assumes ad_entry cannot
>>>> return null. Therefore, on line 370, it adds FINDERINFO_FRTYPEOFF (9) to 0
>>>> and then calls memcpy with a destination address of 9, which causes the
>>>> segmentation violation.
>>>>
>>>> I found about 15 files or so that have code that calls ad_entry, nearly
>>>> all of them unprotected calls. Here are the some of the callers that ARE
>>>> protected against ad_entry returning NULL:
>>>>
>>>> ad_open.c: ad_header_read_ea
>>>> ad_set.c: change_creator
>>>> uniconv.c: check_adouble
>>>> file.c: get_finderinfo
>>>>
>>>> When I modify new_ad_header to return 0 early, when ad_entry returns
>>>> NULL, then I get a different (i.e., downstream) segmentation violation
>>>> backtrace that lays blame on line 23 (in ad_setdate) in file ad_date.c.
>>>>
>>>> Considering how many places in the code have unprotected calls to
>>>> ad_entry, this situation is not looking good.
>>>>
>>>> I'm now wondering if someone failed to merge some or all of a commit
>>>> into the master and this particular branch.
>>>>
>>>> On Mon, Jan 9, 2023 at 10:24 AM Jeff Holt <jef...@gm...>
>>>> wrote:
>>>>
>>>>> Thank you, everyone, for your responses. Nice community.
>>>>>
>>>>> I just built from branch branch-netatalk-3-1 and got the same
>>>>> backtrace in afpd.log.
>>>>>
>>>>> To be fully transparent, this is what I did just now:
>>>>>
>>>>> bootstrap
>>>>> export CFLAGS=-g
>>>>> configure --enable-debug --enable-debugging
>>>>> make clean
>>>>> make
>>>>> # wrt comment 9 of bug 692560, change my_bool to bool in cnid_mysql.c
>>>>> vi ./libatalk/cnid/mysql/cnid_mysql.c
>>>>> make
>>>>> make install
>>>>> netatalk
>>>>> ps -ef | grep afpd # this shows one process
>>>>> gdb -p parent-pid /usr/local/sbin/afpd
>>>>>
>>>>> I set detach-on-fork to off, set a breakpoint in netatalk_panic, and
>>>>> then continued execution.
>>>>>
>>>>> But Finder wouldn't present the list of volumes after connecting. So,
>>>>> I interrupted and tried continuing after the volume dialog was presented.
>>>>>
>>>>> But it never broke.
>>>>>
>>>>> I believe it's because I made gdb attach to the parent. So I tried
>>>>> connecting one more time. After it presented the list of volumes, I looked
>>>>> at the processes again
>>>>>
>>>>> ps -ef | grep afpd # this shows a parent and a child
>>>>>
>>>>> I assumed the child-pid was the one that had given the list of volumes
>>>>> to Finder.
>>>>>
>>>>> gdb -p child-pid /usr/local/sbin/afpd
>>>>>
>>>>> I probably did not need to set detach-on-fork to off but I did anyway,
>>>>> set the breakpoint in netatalk_panic and then continued.
>>>>>
>>>>> When I clicked [OK] in Finder, gdb stopped in netatalk_panic and it
>>>>> printed this when I executed the bt command:
>>>>>
>>>>> Program received signal SIGSEGV, Segmentation fault.
>>>>> __memmove_avx_unaligned_erms () at
>>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>>> Download failed: Function not implemented.  Continuing without source
>>>>> file ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S.
>>>>> 328 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such
>>>>> file or directory.
>>>>> (gdb) bt
>>>>> #0  __memmove_avx_unaligned_erms () at
>>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>>> #1  0x00007f359dd03bc6 in new_ad_header (ad=0x7fff0002aa30,
>>>>> path=0x5555e82f3730 "/u00/family", stp=0x0, adflags=1292) at ad_open.c:370
>>>>> #2  0x00007f359dd06bb4 in ad_open_hf_ea (path=0x5555e82f3730
>>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1251
>>>>> #3  0x00007f359dd06e7a in ad_open_hf (path=0x5555e82f3730
>>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1288
>>>>> #4  0x00007f359dd08c67 in ad_open (ad=0x7fff0002aa30,
>>>>> path=0x5555e82f3730 "/u00/family", adflags=1292) at ad_open.c:1998
>>>>> #5  0x00005555e7fc0790 in getvolparams
>>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>>> st=0x7fff0002b0b0, buf=0x5555e8313d82 "\372\200\002", buflen=0x7fff0002b0a8)
>>>>>     at volume.c:319
>>>>> #6  0x00005555e7fc10bc in stat_vol
>>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>>> rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80) at
>>>>> volume.c:521
>>>>> #7  0x00005555e7fc21c1 in afp_openvol
>>>>>     (obj=0x5555e7fef960 <obj>, ibuf=0x7f359b43801c
>>>>> "\333\374Pz\325\062m`", ibuflen=12, rbuf=0x5555e8313d80 "+N\372\200\002",
>>>>> rbuflen=0x5555e8323d80)
>>>>>     at volume.c:848
>>>>> #8  0x00005555e7f9019f in afp_over_dsi (obj=0x5555e7fef960 <obj>) at
>>>>> afp_dsi.c:627
>>>>> #9  0x00005555e7fb6a4c in dsi_start (obj=0x5555e7fef960 <obj>,
>>>>> dsi=0x5555e8313690, server_children=0x5555e830fa20) at main.c:474
>>>>> #10 0x00005555e7fb6750 in main (ac=4, av=0x7fff0002b5b8) at main.c:417
>>>>>
>>>>> Since everyone was so nice helping me, I will look more closely at the
>>>>> call stack to see if there's anything I can do to fix this. But please feel
>>>>> free to stop me if you think you know what's going one.
>>>>>
>>>>> Warm regards.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Sun, Jan 8, 2023 at 3:44 PM Daniel Markstedt <mar...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Hi Jeff,
>>>>>>
>>>>>> In my experience the challenge with debugging afpd in gdb is to
>>>>>> follow the forked processes.
>>>>>> Start out with "set detach-on-fork off", launch the process, note the
>>>>>> pid that is created, then attach to that pid.
>>>>>> This *should* get you to a state where you can capture the stack
>>>>>> trace.
>>>>>>
>>>>>> Note that my experience is mostly with Netatalk 2.2 so your mileage
>>>>>> may vary.
>>>>>>
>>>>>> BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical
>>>>>> bug fix is in that branch that's not yet in any stable release.
>>>>>>
>>>>>> Best,
>>>>>> Daniel
>>>>>>
>>>>>> On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> TLDR; How can I start netatalk or afpd in gdb so that I can get a
>>>>>>> complete stack trace when a signal is raised? I tried setting a breakpoint
>>>>>>> in netatalk_panic but it's not working.
>>>>>>>
>>>>>>> Quite a few years ago, I had a version of netatalk running on my
>>>>>>> ubuntu server. Then due to some compatibility problems, I could no longer
>>>>>>> use it. I tried upgrading to Ubuntu 21.04 but that didn't help. So I
>>>>>>> switched to samba.
>>>>>>>
>>>>>>> Today I noticed netatalk 3.1.13 is newer than the version I last
>>>>>>> tried.
>>>>>>>
>>>>>>> I compiled and installed libevent-2.1.12-stable.tar.gz and
>>>>>>> netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after
>>>>>>> unmasking), I started the server with this:
>>>>>>>      $ netatalk
>>>>>>>
>>>>>>> Then I tried to "Connect to Server..." to the server using the afp
>>>>>>> protocol instead of the smb protocol. Finder raised the volume selection
>>>>>>> dialog and I chose the volume I wanted to access and clicked [OK]. I
>>>>>>> immediately saw an error dialog.
>>>>>>>
>>>>>>> Then I looked at /var/log/afpd.log and saw this:
>>>>>>>
>>>>>>> Jan 07 17:38:17.584432 afpd[266029] {fault.c:123} (severe:Default):
>>>>>>> ===============================================================
>>>>>>> Jan 07 17:38:17.584524 afpd[266029] {fault.c:124} (severe:Default):
>>>>>>> INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
>>>>>>> Jan 07 17:38:17.584554 afpd[266029] {fault.c:125} (severe:Default):
>>>>>>> ===============================================================
>>>>>>> Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default):
>>>>>>> PANIC: internal error
>>>>>>> Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default):
>>>>>>> BACKTRACE: 17 stack frames:
>>>>>>> Jan 07 17:38:17.585291 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #0 /usr/local/lib/libatalk.so.18(netatalk_panic+0x39) [0x7f42b719338f]
>>>>>>> Jan 07 17:38:17.585315 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #1 /usr/local/lib/libatalk.so.18(+0x485f9) [0x7f42b71935f9]
>>>>>>> Jan 07 17:38:17.585338 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #2 /usr/local/lib/libatalk.so.18(+0x48653) [0x7f42b7193653]
>>>>>>> Jan 07 17:38:17.585361 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #3 /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f42b6f6b040]
>>>>>>> Jan 07 17:38:17.585384 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #4 /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1) [0x7f42b70acff1]
>>>>>>> Jan 07 17:38:17.585409 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #5 /usr/local/lib/libatalk.so.18(+0x1cbc6) [0x7f42b7167bc6]
>>>>>>> Jan 07 17:38:17.585432 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #6 /usr/local/lib/libatalk.so.18(+0x1fbb4) [0x7f42b716abb4]
>>>>>>> Jan 07 17:38:17.585459 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #7 /usr/local/lib/libatalk.so.18(+0x1fe7a) [0x7f42b716ae7a]
>>>>>>> Jan 07 17:38:17.585482 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #8 /usr/local/lib/libatalk.so.18(ad_open+0x3f8) [0x7f42b716cc67]
>>>>>>> Jan 07 17:38:17.585505 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #9 /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
>>>>>>> Jan 07 17:38:17.585528 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #10 /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
>>>>>>> Jan 07 17:38:17.585551 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #11 /usr/local/sbin/afpd(afp_openvol+0x7e0) [0x55e2950971c1]
>>>>>>> Jan 07 17:38:17.585574 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #12 /usr/local/sbin/afpd(afp_over_dsi+0x807) [0x55e29506519f]
>>>>>>> Jan 07 17:38:17.585598 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #13 /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
>>>>>>> Jan 07 17:38:17.585620 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #14 /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
>>>>>>> Jan 07 17:38:17.585644 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #15 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5)
>>>>>>> [0x7f42b6f52565]
>>>>>>> Jan 07 17:38:17.585667 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>>  #16 /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]
>>>>>>>
>>>>>>> Since I'm not a maintainer of this code, this doesn't help me very
>>>>>>> much. At first I thought I needed to compile in debug mode. So, I set
>>>>>>> CFLAGS=-g and configured configured libevent2 and netatalk for debugging:
>>>>>>>
>>>>>>> $ cd ../libevent-2.1.12-stable
>>>>>>> $ ./configure --enable-verbose-debug
>>>>>>> $ make clean
>>>>>>> $ make
>>>>>>> $ make install
>>>>>>> $ cd ../netatalk-3.1.13
>>>>>>> $ ./configure --enable-debug --enable-debugging
>>>>>>> $ make clean
>>>>>>> $ make
>>>>>>> $ make install
>>>>>>>
>>>>>>> Then I use the file command to make sure it would emit "with
>>>>>>> debug_info, not stripped" for the files mentioned in the above backtrace.
>>>>>>> Then I tried the test again. Same thing.
>>>>>>>
>>>>>>> I've written signal handlers and know that emitting line numbers in
>>>>>>> the call stack is non-trivial so I now believe the only way to get that
>>>>>>> information is to run the code in gdb and let its bt command show me what I
>>>>>>> need.
>>>>>>>
>>>>>>> So, how do I start the code so I can get a backtrace? I've tried and
>>>>>>> it's not working.
>>>>>>>
>>>>>>> Thank you.
>>>>>>> _______________________________________________
>>>>>>> Netatalk-devel mailing list
>>>>>>> Net...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>>>>>>
>>>>>>

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Jeff H. <jef...@gm...>]

I'm not a github aficionado but git's my guy. I'll do upon your
encouragement.

On Tue, Jan 10, 2023 at 11:26 AM Daniel Markstedt <mar...@gm...>
wrote:

> Hi Jeff,
>
> It's great to see the deep dive in the codebase! I'm not surprised that
> there are unprotected calls here and there.
> Would you be able to submit this as a PR in Github? I might be spoiled,
> but I find it much easier to read a patchset in PR form.
>
> -> https://github.com/Netatalk/Netatalk
>
> On Mon, Jan 9, 2023 at 5:51 PM Jeff Holt <jef...@gm...> wrote:
>
>> I think I have something partially working. Unified diffs and the changed
>> files are attached. My theme for the changes is this:
>>
>> If ad_entry returns NULL, then its caller will issue a warning instead of
>>> executing a memcpy that would raise SIGSEGV.
>>
>>
>> I don't know if my changes are reasonable but it's behaving infinitely
>> better than it was. I also don't know if the problem is inside ad_entry or
>> if it's a problem with the callers (as I've assumed).
>>
>> I can do all the following on the remote mount:
>> - read a file
>> - write a file
>> - remove a file
>> - change the permission of a file
>>
>> I am highly motivated to fix this problem considering how much faster afp
>> is compared to smb. It's like a race between Carl Lewis and Jerry Lewis.
>>
>> PS I kept the unified diffs separate because I suspect one of the
>> differences needs to be ignored (mysql related boolean datatype).
>>
>> afp.zip contains all the files I changed in branch-netatalk-3-1 as of
>> commit 15687531633e2444d3a6fbe64f86800a159d45cc
>> afp_unif.zip contains the unified diffs for each of the four files that I
>> changed
>>
>> On Mon, Jan 9, 2023 at 1:16 PM Jeff Holt <jef...@gm...>
>> wrote:
>>
>>> There is at least one problem in ad_open.c, possibly two. The immediate
>>> problem is a broken contract in ad_open.c between new_ad_header and
>>> ad_entry.
>>>
>>> ad_entry can return null but new_ad_header assumes ad_entry cannot
>>> return null. Therefore, on line 370, it adds FINDERINFO_FRTYPEOFF (9) to 0
>>> and then calls memcpy with a destination address of 9, which causes the
>>> segmentation violation.
>>>
>>> I found about 15 files or so that have code that calls ad_entry, nearly
>>> all of them unprotected calls. Here are the some of the callers that ARE
>>> protected against ad_entry returning NULL:
>>>
>>> ad_open.c: ad_header_read_ea
>>> ad_set.c: change_creator
>>> uniconv.c: check_adouble
>>> file.c: get_finderinfo
>>>
>>> When I modify new_ad_header to return 0 early, when ad_entry returns
>>> NULL, then I get a different (i.e., downstream) segmentation violation
>>> backtrace that lays blame on line 23 (in ad_setdate) in file ad_date.c.
>>>
>>> Considering how many places in the code have unprotected calls to
>>> ad_entry, this situation is not looking good.
>>>
>>> I'm now wondering if someone failed to merge some or all of a commit
>>> into the master and this particular branch.
>>>
>>> On Mon, Jan 9, 2023 at 10:24 AM Jeff Holt <jef...@gm...>
>>> wrote:
>>>
>>>> Thank you, everyone, for your responses. Nice community.
>>>>
>>>> I just built from branch branch-netatalk-3-1 and got the same backtrace
>>>> in afpd.log.
>>>>
>>>> To be fully transparent, this is what I did just now:
>>>>
>>>> bootstrap
>>>> export CFLAGS=-g
>>>> configure --enable-debug --enable-debugging
>>>> make clean
>>>> make
>>>> # wrt comment 9 of bug 692560, change my_bool to bool in cnid_mysql.c
>>>> vi ./libatalk/cnid/mysql/cnid_mysql.c
>>>> make
>>>> make install
>>>> netatalk
>>>> ps -ef | grep afpd # this shows one process
>>>> gdb -p parent-pid /usr/local/sbin/afpd
>>>>
>>>> I set detach-on-fork to off, set a breakpoint in netatalk_panic, and
>>>> then continued execution.
>>>>
>>>> But Finder wouldn't present the list of volumes after connecting. So, I
>>>> interrupted and tried continuing after the volume dialog was presented.
>>>>
>>>> But it never broke.
>>>>
>>>> I believe it's because I made gdb attach to the parent. So I tried
>>>> connecting one more time. After it presented the list of volumes, I looked
>>>> at the processes again
>>>>
>>>> ps -ef | grep afpd # this shows a parent and a child
>>>>
>>>> I assumed the child-pid was the one that had given the list of volumes
>>>> to Finder.
>>>>
>>>> gdb -p child-pid /usr/local/sbin/afpd
>>>>
>>>> I probably did not need to set detach-on-fork to off but I did anyway,
>>>> set the breakpoint in netatalk_panic and then continued.
>>>>
>>>> When I clicked [OK] in Finder, gdb stopped in netatalk_panic and it
>>>> printed this when I executed the bt command:
>>>>
>>>> Program received signal SIGSEGV, Segmentation fault.
>>>> __memmove_avx_unaligned_erms () at
>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>> Download failed: Function not implemented.  Continuing without source
>>>> file ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S.
>>>> 328 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such
>>>> file or directory.
>>>> (gdb) bt
>>>> #0  __memmove_avx_unaligned_erms () at
>>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>>> #1  0x00007f359dd03bc6 in new_ad_header (ad=0x7fff0002aa30,
>>>> path=0x5555e82f3730 "/u00/family", stp=0x0, adflags=1292) at ad_open.c:370
>>>> #2  0x00007f359dd06bb4 in ad_open_hf_ea (path=0x5555e82f3730
>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1251
>>>> #3  0x00007f359dd06e7a in ad_open_hf (path=0x5555e82f3730
>>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1288
>>>> #4  0x00007f359dd08c67 in ad_open (ad=0x7fff0002aa30,
>>>> path=0x5555e82f3730 "/u00/family", adflags=1292) at ad_open.c:1998
>>>> #5  0x00005555e7fc0790 in getvolparams
>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>> st=0x7fff0002b0b0, buf=0x5555e8313d82 "\372\200\002", buflen=0x7fff0002b0a8)
>>>>     at volume.c:319
>>>> #6  0x00005555e7fc10bc in stat_vol
>>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>>> rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80) at
>>>> volume.c:521
>>>> #7  0x00005555e7fc21c1 in afp_openvol
>>>>     (obj=0x5555e7fef960 <obj>, ibuf=0x7f359b43801c
>>>> "\333\374Pz\325\062m`", ibuflen=12, rbuf=0x5555e8313d80 "+N\372\200\002",
>>>> rbuflen=0x5555e8323d80)
>>>>     at volume.c:848
>>>> #8  0x00005555e7f9019f in afp_over_dsi (obj=0x5555e7fef960 <obj>) at
>>>> afp_dsi.c:627
>>>> #9  0x00005555e7fb6a4c in dsi_start (obj=0x5555e7fef960 <obj>,
>>>> dsi=0x5555e8313690, server_children=0x5555e830fa20) at main.c:474
>>>> #10 0x00005555e7fb6750 in main (ac=4, av=0x7fff0002b5b8) at main.c:417
>>>>
>>>> Since everyone was so nice helping me, I will look more closely at the
>>>> call stack to see if there's anything I can do to fix this. But please feel
>>>> free to stop me if you think you know what's going one.
>>>>
>>>> Warm regards.
>>>>
>>>>
>>>>
>>>>
>>>> On Sun, Jan 8, 2023 at 3:44 PM Daniel Markstedt <mar...@gm...>
>>>> wrote:
>>>>
>>>>> Hi Jeff,
>>>>>
>>>>> In my experience the challenge with debugging afpd in gdb is to follow
>>>>> the forked processes.
>>>>> Start out with "set detach-on-fork off", launch the process, note the
>>>>> pid that is created, then attach to that pid.
>>>>> This *should* get you to a state where you can capture the stack trace.
>>>>>
>>>>> Note that my experience is mostly with Netatalk 2.2 so your mileage
>>>>> may vary.
>>>>>
>>>>> BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical
>>>>> bug fix is in that branch that's not yet in any stable release.
>>>>>
>>>>> Best,
>>>>> Daniel
>>>>>
>>>>> On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...>
>>>>> wrote:
>>>>>
>>>>>> TLDR; How can I start netatalk or afpd in gdb so that I can get a
>>>>>> complete stack trace when a signal is raised? I tried setting a breakpoint
>>>>>> in netatalk_panic but it's not working.
>>>>>>
>>>>>> Quite a few years ago, I had a version of netatalk running on my
>>>>>> ubuntu server. Then due to some compatibility problems, I could no longer
>>>>>> use it. I tried upgrading to Ubuntu 21.04 but that didn't help. So I
>>>>>> switched to samba.
>>>>>>
>>>>>> Today I noticed netatalk 3.1.13 is newer than the version I last
>>>>>> tried.
>>>>>>
>>>>>> I compiled and installed libevent-2.1.12-stable.tar.gz and
>>>>>> netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after
>>>>>> unmasking), I started the server with this:
>>>>>>      $ netatalk
>>>>>>
>>>>>> Then I tried to "Connect to Server..." to the server using the afp
>>>>>> protocol instead of the smb protocol. Finder raised the volume selection
>>>>>> dialog and I chose the volume I wanted to access and clicked [OK]. I
>>>>>> immediately saw an error dialog.
>>>>>>
>>>>>> Then I looked at /var/log/afpd.log and saw this:
>>>>>>
>>>>>> Jan 07 17:38:17.584432 afpd[266029] {fault.c:123} (severe:Default):
>>>>>> ===============================================================
>>>>>> Jan 07 17:38:17.584524 afpd[266029] {fault.c:124} (severe:Default):
>>>>>> INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
>>>>>> Jan 07 17:38:17.584554 afpd[266029] {fault.c:125} (severe:Default):
>>>>>> ===============================================================
>>>>>> Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default):
>>>>>> PANIC: internal error
>>>>>> Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default):
>>>>>> BACKTRACE: 17 stack frames:
>>>>>> Jan 07 17:38:17.585291 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #0 /usr/local/lib/libatalk.so.18(netatalk_panic+0x39) [0x7f42b719338f]
>>>>>> Jan 07 17:38:17.585315 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #1 /usr/local/lib/libatalk.so.18(+0x485f9) [0x7f42b71935f9]
>>>>>> Jan 07 17:38:17.585338 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #2 /usr/local/lib/libatalk.so.18(+0x48653) [0x7f42b7193653]
>>>>>> Jan 07 17:38:17.585361 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #3 /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f42b6f6b040]
>>>>>> Jan 07 17:38:17.585384 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #4 /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1) [0x7f42b70acff1]
>>>>>> Jan 07 17:38:17.585409 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #5 /usr/local/lib/libatalk.so.18(+0x1cbc6) [0x7f42b7167bc6]
>>>>>> Jan 07 17:38:17.585432 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #6 /usr/local/lib/libatalk.so.18(+0x1fbb4) [0x7f42b716abb4]
>>>>>> Jan 07 17:38:17.585459 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #7 /usr/local/lib/libatalk.so.18(+0x1fe7a) [0x7f42b716ae7a]
>>>>>> Jan 07 17:38:17.585482 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #8 /usr/local/lib/libatalk.so.18(ad_open+0x3f8) [0x7f42b716cc67]
>>>>>> Jan 07 17:38:17.585505 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #9 /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
>>>>>> Jan 07 17:38:17.585528 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #10 /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
>>>>>> Jan 07 17:38:17.585551 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #11 /usr/local/sbin/afpd(afp_openvol+0x7e0) [0x55e2950971c1]
>>>>>> Jan 07 17:38:17.585574 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #12 /usr/local/sbin/afpd(afp_over_dsi+0x807) [0x55e29506519f]
>>>>>> Jan 07 17:38:17.585598 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #13 /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
>>>>>> Jan 07 17:38:17.585620 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #14 /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
>>>>>> Jan 07 17:38:17.585644 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #15 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5)
>>>>>> [0x7f42b6f52565]
>>>>>> Jan 07 17:38:17.585667 afpd[266029] {fault.c:103} (severe:Default):
>>>>>>  #16 /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]
>>>>>>
>>>>>> Since I'm not a maintainer of this code, this doesn't help me very
>>>>>> much. At first I thought I needed to compile in debug mode. So, I set
>>>>>> CFLAGS=-g and configured configured libevent2 and netatalk for debugging:
>>>>>>
>>>>>> $ cd ../libevent-2.1.12-stable
>>>>>> $ ./configure --enable-verbose-debug
>>>>>> $ make clean
>>>>>> $ make
>>>>>> $ make install
>>>>>> $ cd ../netatalk-3.1.13
>>>>>> $ ./configure --enable-debug --enable-debugging
>>>>>> $ make clean
>>>>>> $ make
>>>>>> $ make install
>>>>>>
>>>>>> Then I use the file command to make sure it would emit "with
>>>>>> debug_info, not stripped" for the files mentioned in the above backtrace.
>>>>>> Then I tried the test again. Same thing.
>>>>>>
>>>>>> I've written signal handlers and know that emitting line numbers in
>>>>>> the call stack is non-trivial so I now believe the only way to get that
>>>>>> information is to run the code in gdb and let its bt command show me what I
>>>>>> need.
>>>>>>
>>>>>> So, how do I start the code so I can get a backtrace? I've tried and
>>>>>> it's not working.
>>>>>>
>>>>>> Thank you.
>>>>>> _______________________________________________
>>>>>> Netatalk-devel mailing list
>>>>>> Net...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>>>>>
>>>>>

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Daniel M. <mar...@gm...>]

Hi Jeff,

It's great to see the deep dive in the codebase! I'm not surprised that
there are unprotected calls here and there.
Would you be able to submit this as a PR in Github? I might be spoiled, but
I find it much easier to read a patchset in PR form.

-> https://github.com/Netatalk/Netatalk

On Mon, Jan 9, 2023 at 5:51 PM Jeff Holt <jef...@gm...> wrote:

> I think I have something partially working. Unified diffs and the changed
> files are attached. My theme for the changes is this:
>
> If ad_entry returns NULL, then its caller will issue a warning instead of
>> executing a memcpy that would raise SIGSEGV.
>
>
> I don't know if my changes are reasonable but it's behaving infinitely
> better than it was. I also don't know if the problem is inside ad_entry or
> if it's a problem with the callers (as I've assumed).
>
> I can do all the following on the remote mount:
> - read a file
> - write a file
> - remove a file
> - change the permission of a file
>
> I am highly motivated to fix this problem considering how much faster afp
> is compared to smb. It's like a race between Carl Lewis and Jerry Lewis.
>
> PS I kept the unified diffs separate because I suspect one of the
> differences needs to be ignored (mysql related boolean datatype).
>
> afp.zip contains all the files I changed in branch-netatalk-3-1 as of
> commit 15687531633e2444d3a6fbe64f86800a159d45cc
> afp_unif.zip contains the unified diffs for each of the four files that I
> changed
>
> On Mon, Jan 9, 2023 at 1:16 PM Jeff Holt <jef...@gm...> wrote:
>
>> There is at least one problem in ad_open.c, possibly two. The immediate
>> problem is a broken contract in ad_open.c between new_ad_header and
>> ad_entry.
>>
>> ad_entry can return null but new_ad_header assumes ad_entry cannot return
>> null. Therefore, on line 370, it adds FINDERINFO_FRTYPEOFF (9) to 0 and
>> then calls memcpy with a destination address of 9, which causes the
>> segmentation violation.
>>
>> I found about 15 files or so that have code that calls ad_entry, nearly
>> all of them unprotected calls. Here are the some of the callers that ARE
>> protected against ad_entry returning NULL:
>>
>> ad_open.c: ad_header_read_ea
>> ad_set.c: change_creator
>> uniconv.c: check_adouble
>> file.c: get_finderinfo
>>
>> When I modify new_ad_header to return 0 early, when ad_entry returns
>> NULL, then I get a different (i.e., downstream) segmentation violation
>> backtrace that lays blame on line 23 (in ad_setdate) in file ad_date.c.
>>
>> Considering how many places in the code have unprotected calls to
>> ad_entry, this situation is not looking good.
>>
>> I'm now wondering if someone failed to merge some or all of a commit into
>> the master and this particular branch.
>>
>> On Mon, Jan 9, 2023 at 10:24 AM Jeff Holt <jef...@gm...>
>> wrote:
>>
>>> Thank you, everyone, for your responses. Nice community.
>>>
>>> I just built from branch branch-netatalk-3-1 and got the same backtrace
>>> in afpd.log.
>>>
>>> To be fully transparent, this is what I did just now:
>>>
>>> bootstrap
>>> export CFLAGS=-g
>>> configure --enable-debug --enable-debugging
>>> make clean
>>> make
>>> # wrt comment 9 of bug 692560, change my_bool to bool in cnid_mysql.c
>>> vi ./libatalk/cnid/mysql/cnid_mysql.c
>>> make
>>> make install
>>> netatalk
>>> ps -ef | grep afpd # this shows one process
>>> gdb -p parent-pid /usr/local/sbin/afpd
>>>
>>> I set detach-on-fork to off, set a breakpoint in netatalk_panic, and
>>> then continued execution.
>>>
>>> But Finder wouldn't present the list of volumes after connecting. So, I
>>> interrupted and tried continuing after the volume dialog was presented.
>>>
>>> But it never broke.
>>>
>>> I believe it's because I made gdb attach to the parent. So I tried
>>> connecting one more time. After it presented the list of volumes, I looked
>>> at the processes again
>>>
>>> ps -ef | grep afpd # this shows a parent and a child
>>>
>>> I assumed the child-pid was the one that had given the list of volumes
>>> to Finder.
>>>
>>> gdb -p child-pid /usr/local/sbin/afpd
>>>
>>> I probably did not need to set detach-on-fork to off but I did anyway,
>>> set the breakpoint in netatalk_panic and then continued.
>>>
>>> When I clicked [OK] in Finder, gdb stopped in netatalk_panic and it
>>> printed this when I executed the bt command:
>>>
>>> Program received signal SIGSEGV, Segmentation fault.
>>> __memmove_avx_unaligned_erms () at
>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>> Download failed: Function not implemented.  Continuing without source
>>> file ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S.
>>> 328 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such
>>> file or directory.
>>> (gdb) bt
>>> #0  __memmove_avx_unaligned_erms () at
>>> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
>>> #1  0x00007f359dd03bc6 in new_ad_header (ad=0x7fff0002aa30,
>>> path=0x5555e82f3730 "/u00/family", stp=0x0, adflags=1292) at ad_open.c:370
>>> #2  0x00007f359dd06bb4 in ad_open_hf_ea (path=0x5555e82f3730
>>> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1251
>>> #3  0x00007f359dd06e7a in ad_open_hf (path=0x5555e82f3730 "/u00/family",
>>> adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1288
>>> #4  0x00007f359dd08c67 in ad_open (ad=0x7fff0002aa30,
>>> path=0x5555e82f3730 "/u00/family", adflags=1292) at ad_open.c:1998
>>> #5  0x00005555e7fc0790 in getvolparams
>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>> st=0x7fff0002b0b0, buf=0x5555e8313d82 "\372\200\002", buflen=0x7fff0002b0a8)
>>>     at volume.c:319
>>> #6  0x00005555e7fc10bc in stat_vol
>>>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
>>> rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80) at
>>> volume.c:521
>>> #7  0x00005555e7fc21c1 in afp_openvol
>>>     (obj=0x5555e7fef960 <obj>, ibuf=0x7f359b43801c
>>> "\333\374Pz\325\062m`", ibuflen=12, rbuf=0x5555e8313d80 "+N\372\200\002",
>>> rbuflen=0x5555e8323d80)
>>>     at volume.c:848
>>> #8  0x00005555e7f9019f in afp_over_dsi (obj=0x5555e7fef960 <obj>) at
>>> afp_dsi.c:627
>>> #9  0x00005555e7fb6a4c in dsi_start (obj=0x5555e7fef960 <obj>,
>>> dsi=0x5555e8313690, server_children=0x5555e830fa20) at main.c:474
>>> #10 0x00005555e7fb6750 in main (ac=4, av=0x7fff0002b5b8) at main.c:417
>>>
>>> Since everyone was so nice helping me, I will look more closely at the
>>> call stack to see if there's anything I can do to fix this. But please feel
>>> free to stop me if you think you know what's going one.
>>>
>>> Warm regards.
>>>
>>>
>>>
>>>
>>> On Sun, Jan 8, 2023 at 3:44 PM Daniel Markstedt <mar...@gm...>
>>> wrote:
>>>
>>>> Hi Jeff,
>>>>
>>>> In my experience the challenge with debugging afpd in gdb is to follow
>>>> the forked processes.
>>>> Start out with "set detach-on-fork off", launch the process, note the
>>>> pid that is created, then attach to that pid.
>>>> This *should* get you to a state where you can capture the stack trace.
>>>>
>>>> Note that my experience is mostly with Netatalk 2.2 so your mileage may
>>>> vary.
>>>>
>>>> BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical bug
>>>> fix is in that branch that's not yet in any stable release.
>>>>
>>>> Best,
>>>> Daniel
>>>>
>>>> On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...>
>>>> wrote:
>>>>
>>>>> TLDR; How can I start netatalk or afpd in gdb so that I can get a
>>>>> complete stack trace when a signal is raised? I tried setting a breakpoint
>>>>> in netatalk_panic but it's not working.
>>>>>
>>>>> Quite a few years ago, I had a version of netatalk running on my
>>>>> ubuntu server. Then due to some compatibility problems, I could no longer
>>>>> use it. I tried upgrading to Ubuntu 21.04 but that didn't help. So I
>>>>> switched to samba.
>>>>>
>>>>> Today I noticed netatalk 3.1.13 is newer than the version I last tried.
>>>>>
>>>>> I compiled and installed libevent-2.1.12-stable.tar.gz and
>>>>> netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after
>>>>> unmasking), I started the server with this:
>>>>>      $ netatalk
>>>>>
>>>>> Then I tried to "Connect to Server..." to the server using the afp
>>>>> protocol instead of the smb protocol. Finder raised the volume selection
>>>>> dialog and I chose the volume I wanted to access and clicked [OK]. I
>>>>> immediately saw an error dialog.
>>>>>
>>>>> Then I looked at /var/log/afpd.log and saw this:
>>>>>
>>>>> Jan 07 17:38:17.584432 afpd[266029] {fault.c:123} (severe:Default):
>>>>> ===============================================================
>>>>> Jan 07 17:38:17.584524 afpd[266029] {fault.c:124} (severe:Default):
>>>>> INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
>>>>> Jan 07 17:38:17.584554 afpd[266029] {fault.c:125} (severe:Default):
>>>>> ===============================================================
>>>>> Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default):
>>>>> PANIC: internal error
>>>>> Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default):
>>>>> BACKTRACE: 17 stack frames:
>>>>> Jan 07 17:38:17.585291 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #0 /usr/local/lib/libatalk.so.18(netatalk_panic+0x39) [0x7f42b719338f]
>>>>> Jan 07 17:38:17.585315 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #1 /usr/local/lib/libatalk.so.18(+0x485f9) [0x7f42b71935f9]
>>>>> Jan 07 17:38:17.585338 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #2 /usr/local/lib/libatalk.so.18(+0x48653) [0x7f42b7193653]
>>>>> Jan 07 17:38:17.585361 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #3 /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f42b6f6b040]
>>>>> Jan 07 17:38:17.585384 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #4 /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1) [0x7f42b70acff1]
>>>>> Jan 07 17:38:17.585409 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #5 /usr/local/lib/libatalk.so.18(+0x1cbc6) [0x7f42b7167bc6]
>>>>> Jan 07 17:38:17.585432 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #6 /usr/local/lib/libatalk.so.18(+0x1fbb4) [0x7f42b716abb4]
>>>>> Jan 07 17:38:17.585459 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #7 /usr/local/lib/libatalk.so.18(+0x1fe7a) [0x7f42b716ae7a]
>>>>> Jan 07 17:38:17.585482 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #8 /usr/local/lib/libatalk.so.18(ad_open+0x3f8) [0x7f42b716cc67]
>>>>> Jan 07 17:38:17.585505 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #9 /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
>>>>> Jan 07 17:38:17.585528 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #10 /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
>>>>> Jan 07 17:38:17.585551 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #11 /usr/local/sbin/afpd(afp_openvol+0x7e0) [0x55e2950971c1]
>>>>> Jan 07 17:38:17.585574 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #12 /usr/local/sbin/afpd(afp_over_dsi+0x807) [0x55e29506519f]
>>>>> Jan 07 17:38:17.585598 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #13 /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
>>>>> Jan 07 17:38:17.585620 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #14 /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
>>>>> Jan 07 17:38:17.585644 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #15 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5)
>>>>> [0x7f42b6f52565]
>>>>> Jan 07 17:38:17.585667 afpd[266029] {fault.c:103} (severe:Default):
>>>>>  #16 /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]
>>>>>
>>>>> Since I'm not a maintainer of this code, this doesn't help me very
>>>>> much. At first I thought I needed to compile in debug mode. So, I set
>>>>> CFLAGS=-g and configured configured libevent2 and netatalk for debugging:
>>>>>
>>>>> $ cd ../libevent-2.1.12-stable
>>>>> $ ./configure --enable-verbose-debug
>>>>> $ make clean
>>>>> $ make
>>>>> $ make install
>>>>> $ cd ../netatalk-3.1.13
>>>>> $ ./configure --enable-debug --enable-debugging
>>>>> $ make clean
>>>>> $ make
>>>>> $ make install
>>>>>
>>>>> Then I use the file command to make sure it would emit "with
>>>>> debug_info, not stripped" for the files mentioned in the above backtrace.
>>>>> Then I tried the test again. Same thing.
>>>>>
>>>>> I've written signal handlers and know that emitting line numbers in
>>>>> the call stack is non-trivial so I now believe the only way to get that
>>>>> information is to run the code in gdb and let its bt command show me what I
>>>>> need.
>>>>>
>>>>> So, how do I start the code so I can get a backtrace? I've tried and
>>>>> it's not working.
>>>>>
>>>>> Thank you.
>>>>> _______________________________________________
>>>>> Netatalk-devel mailing list
>>>>> Net...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>>>>
>>>>

Re: [Netatalk-devel] Moving Netatalk Releases to github?

[Ralph B. <sl...@sa...>]

On 1/10/23 10:09, Ralph Boehme via Netatalk-devel wrote:
> What would make the whole release process much more streamlined if we 
> would move the release away from Sourceforge and to github. The SF 
> interface for doing the release is quite cumbersome compared to github: 
> it took me 5 minutes to roll the 2.2.7 release, the SF release would 
> take me roughly 10 times more.
> 
> Please check it out here:
> 
> https://github.com/Netatalk/Netatalk/releases/tag/netatalk-2-2-7
I've also created a 3.1.14 release:

https://github.com/Netatalk/Netatalk/releases

Please test and report back! Thank!

-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba

[Netatalk-devel] Moving Netatalk Releases to github?

[Ralph B. <sl...@sa...>]

Hi folks!

I've finally taken the stab looking into fleshing a new Netatalk 2.2.x 
release.

What would make the whole release process much more streamlined if we 
would move the release away from Sourceforge and to github. The SF 
interface for doing the release is quite cumbersome compared to github: 
it took me 5 minutes to roll the 2.2.7 release, the SF release would 
take me roughly 10 times more.

Please check it out here:

https://github.com/Netatalk/Netatalk/releases/tag/netatalk-2-2-7

Thoughts?

Cheers!
-slow

-- 
Ralph Boehme, Samba Team                 https://samba.org/
SerNet Samba Team Lead      https://sernet.de/en/team-samba

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Jeff H. <jef...@gm...>]

There is at least one problem in ad_open.c, possibly two. The immediate
problem is a broken contract in ad_open.c between new_ad_header and
ad_entry.

ad_entry can return null but new_ad_header assumes ad_entry cannot return
null. Therefore, on line 370, it adds FINDERINFO_FRTYPEOFF (9) to 0 and
then calls memcpy with a destination address of 9, which causes the
segmentation violation.

I found about 15 files or so that have code that calls ad_entry, nearly all
of them unprotected calls. Here are the some of the callers that ARE
protected against ad_entry returning NULL:

ad_open.c: ad_header_read_ea
ad_set.c: change_creator
uniconv.c: check_adouble
file.c: get_finderinfo

When I modify new_ad_header to return 0 early, when ad_entry returns NULL,
then I get a different (i.e., downstream) segmentation violation backtrace
that lays blame on line 23 (in ad_setdate) in file ad_date.c.

Considering how many places in the code have unprotected calls to ad_entry,
this situation is not looking good.

I'm now wondering if someone failed to merge some or all of a commit into
the master and this particular branch.

On Mon, Jan 9, 2023 at 10:24 AM Jeff Holt <jef...@gm...> wrote:

> Thank you, everyone, for your responses. Nice community.
>
> I just built from branch branch-netatalk-3-1 and got the same backtrace in
> afpd.log.
>
> To be fully transparent, this is what I did just now:
>
> bootstrap
> export CFLAGS=-g
> configure --enable-debug --enable-debugging
> make clean
> make
> # wrt comment 9 of bug 692560, change my_bool to bool in cnid_mysql.c
> vi ./libatalk/cnid/mysql/cnid_mysql.c
> make
> make install
> netatalk
> ps -ef | grep afpd # this shows one process
> gdb -p parent-pid /usr/local/sbin/afpd
>
> I set detach-on-fork to off, set a breakpoint in netatalk_panic, and then
> continued execution.
>
> But Finder wouldn't present the list of volumes after connecting. So, I
> interrupted and tried continuing after the volume dialog was presented.
>
> But it never broke.
>
> I believe it's because I made gdb attach to the parent. So I tried
> connecting one more time. After it presented the list of volumes, I looked
> at the processes again
>
> ps -ef | grep afpd # this shows a parent and a child
>
> I assumed the child-pid was the one that had given the list of volumes to
> Finder.
>
> gdb -p child-pid /usr/local/sbin/afpd
>
> I probably did not need to set detach-on-fork to off but I did anyway, set
> the breakpoint in netatalk_panic and then continued.
>
> When I clicked [OK] in Finder, gdb stopped in netatalk_panic and it
> printed this when I executed the bt command:
>
> Program received signal SIGSEGV, Segmentation fault.
> __memmove_avx_unaligned_erms () at
> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
> Download failed: Function not implemented.  Continuing without source file
> ./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S.
> 328 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file
> or directory.
> (gdb) bt
> #0  __memmove_avx_unaligned_erms () at
> ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
> #1  0x00007f359dd03bc6 in new_ad_header (ad=0x7fff0002aa30,
> path=0x5555e82f3730 "/u00/family", stp=0x0, adflags=1292) at ad_open.c:370
> #2  0x00007f359dd06bb4 in ad_open_hf_ea (path=0x5555e82f3730
> "/u00/family", adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1251
> #3  0x00007f359dd06e7a in ad_open_hf (path=0x5555e82f3730 "/u00/family",
> adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1288
> #4  0x00007f359dd08c67 in ad_open (ad=0x7fff0002aa30, path=0x5555e82f3730
> "/u00/family", adflags=1292) at ad_open.c:1998
> #5  0x00005555e7fc0790 in getvolparams
>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
> st=0x7fff0002b0b0, buf=0x5555e8313d82 "\372\200\002", buflen=0x7fff0002b0a8)
>     at volume.c:319
> #6  0x00005555e7fc10bc in stat_vol
>     (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
> rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80) at
> volume.c:521
> #7  0x00005555e7fc21c1 in afp_openvol
>     (obj=0x5555e7fef960 <obj>, ibuf=0x7f359b43801c "\333\374Pz\325\062m`",
> ibuflen=12, rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80)
>     at volume.c:848
> #8  0x00005555e7f9019f in afp_over_dsi (obj=0x5555e7fef960 <obj>) at
> afp_dsi.c:627
> #9  0x00005555e7fb6a4c in dsi_start (obj=0x5555e7fef960 <obj>,
> dsi=0x5555e8313690, server_children=0x5555e830fa20) at main.c:474
> #10 0x00005555e7fb6750 in main (ac=4, av=0x7fff0002b5b8) at main.c:417
>
> Since everyone was so nice helping me, I will look more closely at the
> call stack to see if there's anything I can do to fix this. But please feel
> free to stop me if you think you know what's going one.
>
> Warm regards.
>
>
>
>
> On Sun, Jan 8, 2023 at 3:44 PM Daniel Markstedt <mar...@gm...>
> wrote:
>
>> Hi Jeff,
>>
>> In my experience the challenge with debugging afpd in gdb is to follow
>> the forked processes.
>> Start out with "set detach-on-fork off", launch the process, note the pid
>> that is created, then attach to that pid.
>> This *should* get you to a state where you can capture the stack trace.
>>
>> Note that my experience is mostly with Netatalk 2.2 so your mileage may
>> vary.
>>
>> BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical bug
>> fix is in that branch that's not yet in any stable release.
>>
>> Best,
>> Daniel
>>
>> On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...>
>> wrote:
>>
>>> TLDR; How can I start netatalk or afpd in gdb so that I can get a
>>> complete stack trace when a signal is raised? I tried setting a breakpoint
>>> in netatalk_panic but it's not working.
>>>
>>> Quite a few years ago, I had a version of netatalk running on my ubuntu
>>> server. Then due to some compatibility problems, I could no longer use it.
>>> I tried upgrading to Ubuntu 21.04 but that didn't help. So I switched to
>>> samba.
>>>
>>> Today I noticed netatalk 3.1.13 is newer than the version I last tried.
>>>
>>> I compiled and installed libevent-2.1.12-stable.tar.gz and
>>> netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after
>>> unmasking), I started the server with this:
>>>      $ netatalk
>>>
>>> Then I tried to "Connect to Server..." to the server using the afp
>>> protocol instead of the smb protocol. Finder raised the volume selection
>>> dialog and I chose the volume I wanted to access and clicked [OK]. I
>>> immediately saw an error dialog.
>>>
>>> Then I looked at /var/log/afpd.log and saw this:
>>>
>>> Jan 07 17:38:17.584432 afpd[266029] {fault.c:123} (severe:Default):
>>> ===============================================================
>>> Jan 07 17:38:17.584524 afpd[266029] {fault.c:124} (severe:Default):
>>> INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
>>> Jan 07 17:38:17.584554 afpd[266029] {fault.c:125} (severe:Default):
>>> ===============================================================
>>> Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default):
>>> PANIC: internal error
>>> Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default):
>>> BACKTRACE: 17 stack frames:
>>> Jan 07 17:38:17.585291 afpd[266029] {fault.c:103} (severe:Default):  #0
>>> /usr/local/lib/libatalk.so.18(netatalk_panic+0x39) [0x7f42b719338f]
>>> Jan 07 17:38:17.585315 afpd[266029] {fault.c:103} (severe:Default):  #1
>>> /usr/local/lib/libatalk.so.18(+0x485f9) [0x7f42b71935f9]
>>> Jan 07 17:38:17.585338 afpd[266029] {fault.c:103} (severe:Default):  #2
>>> /usr/local/lib/libatalk.so.18(+0x48653) [0x7f42b7193653]
>>> Jan 07 17:38:17.585361 afpd[266029] {fault.c:103} (severe:Default):  #3
>>> /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f42b6f6b040]
>>> Jan 07 17:38:17.585384 afpd[266029] {fault.c:103} (severe:Default):  #4
>>> /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1) [0x7f42b70acff1]
>>> Jan 07 17:38:17.585409 afpd[266029] {fault.c:103} (severe:Default):  #5
>>> /usr/local/lib/libatalk.so.18(+0x1cbc6) [0x7f42b7167bc6]
>>> Jan 07 17:38:17.585432 afpd[266029] {fault.c:103} (severe:Default):  #6
>>> /usr/local/lib/libatalk.so.18(+0x1fbb4) [0x7f42b716abb4]
>>> Jan 07 17:38:17.585459 afpd[266029] {fault.c:103} (severe:Default):  #7
>>> /usr/local/lib/libatalk.so.18(+0x1fe7a) [0x7f42b716ae7a]
>>> Jan 07 17:38:17.585482 afpd[266029] {fault.c:103} (severe:Default):  #8
>>> /usr/local/lib/libatalk.so.18(ad_open+0x3f8) [0x7f42b716cc67]
>>> Jan 07 17:38:17.585505 afpd[266029] {fault.c:103} (severe:Default):  #9
>>> /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
>>> Jan 07 17:38:17.585528 afpd[266029] {fault.c:103} (severe:Default):  #10
>>> /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
>>> Jan 07 17:38:17.585551 afpd[266029] {fault.c:103} (severe:Default):  #11
>>> /usr/local/sbin/afpd(afp_openvol+0x7e0) [0x55e2950971c1]
>>> Jan 07 17:38:17.585574 afpd[266029] {fault.c:103} (severe:Default):  #12
>>> /usr/local/sbin/afpd(afp_over_dsi+0x807) [0x55e29506519f]
>>> Jan 07 17:38:17.585598 afpd[266029] {fault.c:103} (severe:Default):  #13
>>> /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
>>> Jan 07 17:38:17.585620 afpd[266029] {fault.c:103} (severe:Default):  #14
>>> /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
>>> Jan 07 17:38:17.585644 afpd[266029] {fault.c:103} (severe:Default):  #15
>>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5) [0x7f42b6f52565]
>>> Jan 07 17:38:17.585667 afpd[266029] {fault.c:103} (severe:Default):  #16
>>> /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]
>>>
>>> Since I'm not a maintainer of this code, this doesn't help me very much.
>>> At first I thought I needed to compile in debug mode. So, I set CFLAGS=-g
>>> and configured configured libevent2 and netatalk for debugging:
>>>
>>> $ cd ../libevent-2.1.12-stable
>>> $ ./configure --enable-verbose-debug
>>> $ make clean
>>> $ make
>>> $ make install
>>> $ cd ../netatalk-3.1.13
>>> $ ./configure --enable-debug --enable-debugging
>>> $ make clean
>>> $ make
>>> $ make install
>>>
>>> Then I use the file command to make sure it would emit "with debug_info,
>>> not stripped" for the files mentioned in the above backtrace. Then I tried
>>> the test again. Same thing.
>>>
>>> I've written signal handlers and know that emitting line numbers in the
>>> call stack is non-trivial so I now believe the only way to get that
>>> information is to run the code in gdb and let its bt command show me what I
>>> need.
>>>
>>> So, how do I start the code so I can get a backtrace? I've tried and
>>> it's not working.
>>>
>>> Thank you.
>>> _______________________________________________
>>> Netatalk-devel mailing list
>>> Net...@li...
>>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>>
>>

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Jeff H. <jef...@gm...>]

Thank you, everyone, for your responses. Nice community.

I just built from branch branch-netatalk-3-1 and got the same backtrace in
afpd.log.

To be fully transparent, this is what I did just now:

bootstrap
export CFLAGS=-g
configure --enable-debug --enable-debugging
make clean
make
# wrt comment 9 of bug 692560, change my_bool to bool in cnid_mysql.c
vi ./libatalk/cnid/mysql/cnid_mysql.c
make
make install
netatalk
ps -ef | grep afpd # this shows one process
gdb -p parent-pid /usr/local/sbin/afpd

I set detach-on-fork to off, set a breakpoint in netatalk_panic, and then
continued execution.

But Finder wouldn't present the list of volumes after connecting. So, I
interrupted and tried continuing after the volume dialog was presented.

But it never broke.

I believe it's because I made gdb attach to the parent. So I tried
connecting one more time. After it presented the list of volumes, I looked
at the processes again

ps -ef | grep afpd # this shows a parent and a child

I assumed the child-pid was the one that had given the list of volumes to
Finder.

gdb -p child-pid /usr/local/sbin/afpd

I probably did not need to set detach-on-fork to off but I did anyway, set
the breakpoint in netatalk_panic and then continued.

When I clicked [OK] in Finder, gdb stopped in netatalk_panic and it printed
this when I executed the bt command:

Program received signal SIGSEGV, Segmentation fault.
__memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
Download failed: Function not implemented.  Continuing without source file
./string/../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S.
328 ../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S: No such file
or directory.
(gdb) bt
#0  __memmove_avx_unaligned_erms () at
../sysdeps/x86_64/multiarch/memmove-vec-unaligned-erms.S:328
#1  0x00007f359dd03bc6 in new_ad_header (ad=0x7fff0002aa30,
path=0x5555e82f3730 "/u00/family", stp=0x0, adflags=1292) at ad_open.c:370
#2  0x00007f359dd06bb4 in ad_open_hf_ea (path=0x5555e82f3730 "/u00/family",
adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1251
#3  0x00007f359dd06e7a in ad_open_hf (path=0x5555e82f3730 "/u00/family",
adflags=1292, mode=438, ad=0x7fff0002aa30) at ad_open.c:1288
#4  0x00007f359dd08c67 in ad_open (ad=0x7fff0002aa30, path=0x5555e82f3730
"/u00/family", adflags=1292) at ad_open.c:1998
#5  0x00005555e7fc0790 in getvolparams
    (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
st=0x7fff0002b0b0, buf=0x5555e8313d82 "\372\200\002", buflen=0x7fff0002b0a8)
    at volume.c:319
#6  0x00005555e7fc10bc in stat_vol
    (obj=0x5555e7fef960 <obj>, bitmap=32, vol=0x5555e833c930,
rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80) at
volume.c:521
#7  0x00005555e7fc21c1 in afp_openvol
    (obj=0x5555e7fef960 <obj>, ibuf=0x7f359b43801c "\333\374Pz\325\062m`",
ibuflen=12, rbuf=0x5555e8313d80 "+N\372\200\002", rbuflen=0x5555e8323d80)
    at volume.c:848
#8  0x00005555e7f9019f in afp_over_dsi (obj=0x5555e7fef960 <obj>) at
afp_dsi.c:627
#9  0x00005555e7fb6a4c in dsi_start (obj=0x5555e7fef960 <obj>,
dsi=0x5555e8313690, server_children=0x5555e830fa20) at main.c:474
#10 0x00005555e7fb6750 in main (ac=4, av=0x7fff0002b5b8) at main.c:417

Since everyone was so nice helping me, I will look more closely at the call
stack to see if there's anything I can do to fix this. But please feel free
to stop me if you think you know what's going one.

Warm regards.




On Sun, Jan 8, 2023 at 3:44 PM Daniel Markstedt <mar...@gm...> wrote:

> Hi Jeff,
>
> In my experience the challenge with debugging afpd in gdb is to follow the
> forked processes.
> Start out with "set detach-on-fork off", launch the process, note the pid
> that is created, then attach to that pid.
> This *should* get you to a state where you can capture the stack trace.
>
> Note that my experience is mostly with Netatalk 2.2 so your mileage may
> vary.
>
> BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical bug
> fix is in that branch that's not yet in any stable release.
>
> Best,
> Daniel
>
> On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...> wrote:
>
>> TLDR; How can I start netatalk or afpd in gdb so that I can get a
>> complete stack trace when a signal is raised? I tried setting a breakpoint
>> in netatalk_panic but it's not working.
>>
>> Quite a few years ago, I had a version of netatalk running on my ubuntu
>> server. Then due to some compatibility problems, I could no longer use it.
>> I tried upgrading to Ubuntu 21.04 but that didn't help. So I switched to
>> samba.
>>
>> Today I noticed netatalk 3.1.13 is newer than the version I last tried.
>>
>> I compiled and installed libevent-2.1.12-stable.tar.gz and
>> netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after
>> unmasking), I started the server with this:
>>      $ netatalk
>>
>> Then I tried to "Connect to Server..." to the server using the afp
>> protocol instead of the smb protocol. Finder raised the volume selection
>> dialog and I chose the volume I wanted to access and clicked [OK]. I
>> immediately saw an error dialog.
>>
>> Then I looked at /var/log/afpd.log and saw this:
>>
>> Jan 07 17:38:17.584432 afpd[266029] {fault.c:123} (severe:Default):
>> ===============================================================
>> Jan 07 17:38:17.584524 afpd[266029] {fault.c:124} (severe:Default):
>> INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
>> Jan 07 17:38:17.584554 afpd[266029] {fault.c:125} (severe:Default):
>> ===============================================================
>> Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default): PANIC:
>> internal error
>> Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default):
>> BACKTRACE: 17 stack frames:
>> Jan 07 17:38:17.585291 afpd[266029] {fault.c:103} (severe:Default):  #0
>> /usr/local/lib/libatalk.so.18(netatalk_panic+0x39) [0x7f42b719338f]
>> Jan 07 17:38:17.585315 afpd[266029] {fault.c:103} (severe:Default):  #1
>> /usr/local/lib/libatalk.so.18(+0x485f9) [0x7f42b71935f9]
>> Jan 07 17:38:17.585338 afpd[266029] {fault.c:103} (severe:Default):  #2
>> /usr/local/lib/libatalk.so.18(+0x48653) [0x7f42b7193653]
>> Jan 07 17:38:17.585361 afpd[266029] {fault.c:103} (severe:Default):  #3
>> /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f42b6f6b040]
>> Jan 07 17:38:17.585384 afpd[266029] {fault.c:103} (severe:Default):  #4
>> /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1) [0x7f42b70acff1]
>> Jan 07 17:38:17.585409 afpd[266029] {fault.c:103} (severe:Default):  #5
>> /usr/local/lib/libatalk.so.18(+0x1cbc6) [0x7f42b7167bc6]
>> Jan 07 17:38:17.585432 afpd[266029] {fault.c:103} (severe:Default):  #6
>> /usr/local/lib/libatalk.so.18(+0x1fbb4) [0x7f42b716abb4]
>> Jan 07 17:38:17.585459 afpd[266029] {fault.c:103} (severe:Default):  #7
>> /usr/local/lib/libatalk.so.18(+0x1fe7a) [0x7f42b716ae7a]
>> Jan 07 17:38:17.585482 afpd[266029] {fault.c:103} (severe:Default):  #8
>> /usr/local/lib/libatalk.so.18(ad_open+0x3f8) [0x7f42b716cc67]
>> Jan 07 17:38:17.585505 afpd[266029] {fault.c:103} (severe:Default):  #9
>> /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
>> Jan 07 17:38:17.585528 afpd[266029] {fault.c:103} (severe:Default):  #10
>> /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
>> Jan 07 17:38:17.585551 afpd[266029] {fault.c:103} (severe:Default):  #11
>> /usr/local/sbin/afpd(afp_openvol+0x7e0) [0x55e2950971c1]
>> Jan 07 17:38:17.585574 afpd[266029] {fault.c:103} (severe:Default):  #12
>> /usr/local/sbin/afpd(afp_over_dsi+0x807) [0x55e29506519f]
>> Jan 07 17:38:17.585598 afpd[266029] {fault.c:103} (severe:Default):  #13
>> /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
>> Jan 07 17:38:17.585620 afpd[266029] {fault.c:103} (severe:Default):  #14
>> /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
>> Jan 07 17:38:17.585644 afpd[266029] {fault.c:103} (severe:Default):  #15
>> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5) [0x7f42b6f52565]
>> Jan 07 17:38:17.585667 afpd[266029] {fault.c:103} (severe:Default):  #16
>> /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]
>>
>> Since I'm not a maintainer of this code, this doesn't help me very much.
>> At first I thought I needed to compile in debug mode. So, I set CFLAGS=-g
>> and configured configured libevent2 and netatalk for debugging:
>>
>> $ cd ../libevent-2.1.12-stable
>> $ ./configure --enable-verbose-debug
>> $ make clean
>> $ make
>> $ make install
>> $ cd ../netatalk-3.1.13
>> $ ./configure --enable-debug --enable-debugging
>> $ make clean
>> $ make
>> $ make install
>>
>> Then I use the file command to make sure it would emit "with debug_info,
>> not stripped" for the files mentioned in the above backtrace. Then I tried
>> the test again. Same thing.
>>
>> I've written signal handlers and know that emitting line numbers in the
>> call stack is non-trivial so I now believe the only way to get that
>> information is to run the code in gdb and let its bt command show me what I
>> need.
>>
>> So, how do I start the code so I can get a backtrace? I've tried and it's
>> not working.
>>
>> Thank you.
>> _______________________________________________
>> Netatalk-devel mailing list
>> Net...@li...
>> https://lists.sourceforge.net/lists/listinfo/netatalk-devel
>>
>

Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

[Andrew B. <kni...@ou...>]

I can second what Daniel mentioned. That crash may be what was discussed in multiple github issues. Here is where the bulk of the conversation was:
https://github.com/Netatalk/Netatalk/pull/174

Try patching your code with this and see if the crash goes away.
https://patch-diff.githubusercontent.com/raw/Netatalk/Netatalk/pull/174.patch

Thanks,
Andy

No Trees were killed in the sending of this message.
However, a large number of electrons were terribly inconvenienced.
________________________________
From: Daniel Markstedt <mar...@gm...>
Sent: Sunday, January 8, 2023 3:43 PM
To: Jeff Holt <jef...@gm...>
Cc: net...@li... <net...@li...>
Subject: Re: [Netatalk-devel] How to execute the code using gdb to get a complete stack trace

Hi Jeff,

In my experience the challenge with debugging afpd in gdb is to follow the forked processes.
Start out with "set detach-on-fork off", launch the process, note the pid that is created, then attach to that pid.
This *should* get you to a state where you can capture the stack trace.

Note that my experience is mostly with Netatalk 2.2 so your mileage may vary.

BTW, have you tried bleeding edge "branch-netatalk-3-1"? A critical bug fix is in that branch that's not yet in any stable release.

Best,
Daniel

On Sat, Jan 7, 2023 at 3:50 PM Jeff Holt <jef...@gm...<mailto:jef...@gm...>> wrote:
TLDR; How can I start netatalk or afpd in gdb so that I can get a complete stack trace when a signal is raised? I tried setting a breakpoint in netatalk_panic but it's not working.

Quite a few years ago, I had a version of netatalk running on my ubuntu server. Then due to some compatibility problems, I could no longer use it. I tried upgrading to Ubuntu 21.04 but that didn't help. So I switched to samba.

Today I noticed netatalk 3.1.13 is newer than the version I last tried.

I compiled and installed libevent-2.1.12-stable.tar.gz and netatalk-3.1.13.tar.gz. When I had trouble starting the service (even after unmasking), I started the server with this:
     $ netatalk

Then I tried to "Connect to Server..." to the server using the afp protocol instead of the smb protocol. Finder raised the volume selection dialog and I chose the volume I wanted to access and clicked [OK]. I immediately saw an error dialog.

Then I looked at /var/log/afpd.log and saw this:

Jan 07 17:38:17.584432 afpd[266029] {fault.c:123} (severe:Default): ===============================================================
Jan 07 17:38:17.584524 afpd[266029] {fault.c:124} (severe:Default): INTERNAL ERROR: Signal 11 in pid 266029 (3.1.13)
Jan 07 17:38:17.584554 afpd[266029] {fault.c:125} (severe:Default): ===============================================================
Jan 07 17:38:17.585224 afpd[266029] {fault.c:96} (severe:Default): PANIC: internal error
Jan 07 17:38:17.585265 afpd[266029] {fault.c:97} (severe:Default): BACKTRACE: 17 stack frames:
Jan 07 17:38:17.585291 afpd[266029] {fault.c:103} (severe:Default):  #0 /usr/local/lib/libatalk.so.18(netatalk_panic+0x39) [0x7f42b719338f]
Jan 07 17:38:17.585315 afpd[266029] {fault.c:103} (severe:Default):  #1 /usr/local/lib/libatalk.so.18(+0x485f9) [0x7f42b71935f9]
Jan 07 17:38:17.585338 afpd[266029] {fault.c:103} (severe:Default):  #2 /usr/local/lib/libatalk.so.18(+0x48653) [0x7f42b7193653]
Jan 07 17:38:17.585361 afpd[266029] {fault.c:103} (severe:Default):  #3 /lib/x86_64-linux-gnu/libc.so.6(+0x41040) [0x7f42b6f6b040]
Jan 07 17:38:17.585384 afpd[266029] {fault.c:103} (severe:Default):  #4 /lib/x86_64-linux-gnu/libc.so.6(+0x182ff1) [0x7f42b70acff1]
Jan 07 17:38:17.585409 afpd[266029] {fault.c:103} (severe:Default):  #5 /usr/local/lib/libatalk.so.18(+0x1cbc6) [0x7f42b7167bc6]
Jan 07 17:38:17.585432 afpd[266029] {fault.c:103} (severe:Default):  #6 /usr/local/lib/libatalk.so.18(+0x1fbb4) [0x7f42b716abb4]
Jan 07 17:38:17.585459 afpd[266029] {fault.c:103} (severe:Default):  #7 /usr/local/lib/libatalk.so.18(+0x1fe7a) [0x7f42b716ae7a]
Jan 07 17:38:17.585482 afpd[266029] {fault.c:103} (severe:Default):  #8 /usr/local/lib/libatalk.so.18(ad_open+0x3f8) [0x7f42b716cc67]
Jan 07 17:38:17.585505 afpd[266029] {fault.c:103} (severe:Default):  #9 /usr/local/sbin/afpd(+0x3f790) [0x55e295095790]
Jan 07 17:38:17.585528 afpd[266029] {fault.c:103} (severe:Default):  #10 /usr/local/sbin/afpd(+0x400bc) [0x55e2950960bc]
Jan 07 17:38:17.585551 afpd[266029] {fault.c:103} (severe:Default):  #11 /usr/local/sbin/afpd(afp_openvol+0x7e0) [0x55e2950971c1]
Jan 07 17:38:17.585574 afpd[266029] {fault.c:103} (severe:Default):  #12 /usr/local/sbin/afpd(afp_over_dsi+0x807) [0x55e29506519f]
Jan 07 17:38:17.585598 afpd[266029] {fault.c:103} (severe:Default):  #13 /usr/local/sbin/afpd(+0x35a4c) [0x55e29508ba4c]
Jan 07 17:38:17.585620 afpd[266029] {fault.c:103} (severe:Default):  #14 /usr/local/sbin/afpd(main+0xc13) [0x55e29508b750]
Jan 07 17:38:17.585644 afpd[266029] {fault.c:103} (severe:Default):  #15 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xd5) [0x7f42b6f52565]
Jan 07 17:38:17.585667 afpd[266029] {fault.c:103} (severe:Default):  #16 /usr/local/sbin/afpd(_start+0x2e) [0x55e295062c0e]

Since I'm not a maintainer of this code, this doesn't help me very much. At first I thought I needed to compile in debug mode. So, I set CFLAGS=-g and configured configured libevent2 and netatalk for debugging:

$ cd ../libevent-2.1.12-stable
$ ./configure --enable-verbose-debug
$ make clean
$ make
$ make install
$ cd ../netatalk-3.1.13
$ ./configure --enable-debug --enable-debugging
$ make clean
$ make
$ make install

Then I use the file command to make sure it would emit "with debug_info, not stripped" for the files mentioned in the above backtrace. Then I tried the test again. Same thing.

I've written signal handlers and know that emitting line numbers in the call stack is non-trivial so I now believe the only way to get that information is to run the code in gdb and let its bt command show me what I need.

So, how do I start the code so I can get a backtrace? I've tried and it's not working.

Thank you.
_______________________________________________
Netatalk-devel mailing list
Net...@li...<mailto:Net...@li...>
https://lists.sourceforge.net/lists/listinfo/netatalk-devel