Subversion 1.14.1 and serf 1.3.9

[Tomasz Lubinski]

Is it possible to use subversion 1.14.1 with serf 1.3.9?
Documentation says: ' 7. Apache Serf library 1.3.4 or newer (OPTIONAL)' but when used with
- SERF 1.3.9, and
- OpenSSL 3.0

I've got segmentation fault from SERF, near:
svn_ra_serf__open ->
svn_ra_serf__exchange_capabilities ->
svn_ra_serf__context_run_one ->
svn_ra_serf__context_run_wait ->
svn_ra_serf__context_run ->
serf_context_run ->
serf_event_trigger ->
serf_process_connection ->
read_from_connection ->
handle_response

OS: Windows 10.

With incorrect user password it returns without segmentation fault.
When not accepted SSL failures also returns without segmentation fault.

Regards,
Tomasz Lubinski

[Daniel Sahlberg]

If I understand you correctly, you get the crash when doing some operation with a correct password (and SSL certificate)? Is it a specific operation or do you always get the crasch? I think there has been reports here or in the TortoiseSVN forum with similar errors caused by firewalls filtering/closing the connection, but I'm a bit short on time to dig them up in the archive.

I'm running TortoiseSVN 1.14.1 which is built using Serf 1.3.9 and OpenSSL 1.11.1l. I have no problems with this build.

Possibly OpenSSL 3 is not well tested (or even not tested at all, considering it was released 2021-09-07).

Are you building yourself or are you using a binary distribution?

Can you try a version with OpenSSL 1.1?

Kind regards,

Daniel

[Daniel Sahlberg]

Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski <t.lub...@verocel.pl>:

Yes problem occurs only with correct user/password (self-signed SSL certificate used). In case of incorrect user/password or repository name, it ends with correct error message without segmentation fault.

The problem is when I’m trying to open RA session using svn_client_open_ra_session.

I’m using my build.

Any chance you can verify if it is a problem only when using OpenSSL 3 (ie did you try it with OpenSSL 1.1.1)?

Kind regards,

Daniel

[Tomasz Lubinski]

Yes problem occurs only with correct user/password (self-signed SSL certificate used). In case of incorrect user/password or repository name, it ends with correct error message without segmentation fault.

The problem is when I’m trying to open RA session using svn_client_open_ra_session.

I’m using my build.

 

Regards,

Tomek L

[Tomasz Lubinski]

I suppose that openssl is not a problem becuase when I used http protocol instead of https the problem is still the same.

 

Tomek L

 

From: Daniel Sahlberg <daniel.l...@gmail.com>
Sent: Wednesday, October 20, 2021 11:18 AM
To: Tomasz Lubinski <t.lub...@verocel.pl>
Cc: Subversion <us...@subversion.apache.org>
Subject: Re: Subversion 1.14.1 and serf 1.3.9

 

Den ons 20 okt. 2021 kl 10:35 skrev Tomasz Lubinski <t.lub...@verocel.pl>:

[Tomasz Lubinski]

I’ve checked with OPENSSL 1.1.1l, it seems that it solves problem with segmentation fault. Now I receive message:

Error running context: The server unexpectedly closed the connection.

 

 

Tomek L

 

From: Daniel Sahlberg <daniel.l...@gmail.com>
Sent: Wednesday, October 20, 2021 12:03 PM
To: Tomasz Lubinski <t.lub...@verocel.pl>
Cc: Subversion <us...@subversion.apache.org>
Subject: Re: Subversion 1.14.1 and serf 1.3.9

 

Den ons 20 okt. 2021 kl 11:58 skrev Tomasz Lubinski <t.lub...@verocel.pl>:

[Daniel Sahlberg]

Den ons 20 okt. 2021 13:49Tomasz Lubinski <t.lub...@verocel.pl> skrev:

I’ve checked with OPENSSL 1.1.1l, it seems that it solves problem with segmentation fault. Now I receive message:

Error running context: The server unexpectedly closed the connection.

OK. It is obviously a fault if OpenSSL triggers a segfault if it looses the connection to the server, but just loosing the connection is bad in itself. 

Do you get any error messages in the server log? What is the server version (and possibly platform/distribution)?

Is there any chance that a firewall (either hardware or software) is blocking the connection? 

Kind regards 

Daniel 

[Tomasz Lubinski]

I tried once again, now with svn.exe built from 1.14.1 sources. With OPENSSL 1.1.1l. It seems that it crashes somewhere in zlib.

Logs attached.

[Daniel Sahlberg]

Den tors 21 okt. 2021 kl 07:58 skrev Tomasz Lubinski <t.lub...@verocel.pl>:

I tried once again, now with svn.exe built from 1.14.1 sources. With OPENSSL 1.1.1l. It seems that it crashes somewhere in zlib.

Logs attached.

Can you check the server logs and firewalls as I asked in the other mail?

I think we have seen crashes in zlib if zlib gets incomplete data. Which would indicate that either the server is crashing or that a firewall cuts of the connection.

Kind regards

Daniel

(PS. Please put your post below the text you are replying to, it makes it a bit easier to follow the discussion compared to top-posting).

[Tomasz Lubinski]

I’m using Virtual SVN, server shows accepted connection with code 200.

 

I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib 1.2.7 (that was used by me some time ago) and it seems that it works OK, now.

Very strange problem with assembly code in zlib 1.2.11.

[Daniel Sahlberg]

Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski <t.lub...@verocel.pl>:

I’m using Virtual SVN, server shows accepted connection with code 200.

 

I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib 1.2.7 (that was used by me some time ago) and it seems that it works OK, now.

Very strange problem with assembly code in zlib 1.2.11.

 

Tomek L

Thanks for reporting back! That is indeed a very strange problem, even more so since TortoiseSVN seems to use zlib 1.2.11.

Maybe you can check the same action using TortoiseSVN?

Kind regards,

Daniel

[Johan Corveleyn]

On Thu, Oct 21, 2021 at 2:00 PM Daniel Sahlberg
<daniel.l...@gmail.com> wrote:
>
> Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski <t.lub...@verocel.pl>:
>>
>> I’m using Virtual SVN, server shows accepted connection with code 200.
>>
>>
>>
>> I’ve found the problem. There is a problem with zlib 1.2.11. I use zlib 1.2.7 (that was used by me some time ago) and it seems that it works OK, now.
>>
>> Very strange problem with assembly code in zlib 1.2.11.
>>
>>
>>
>> Tomek L
>
>
> Thanks for reporting back! That is indeed a very strange problem, even more so since TortoiseSVN seems to use zlib 1.2.11.
>
> Maybe you can check the same action using TortoiseSVN?
>
> Kind regards,
> Daniel

Indeed, zlib's assembly code seems to be unreliable on Windows. When I
build / test (for signing new releases) on Windows, I never use the
assembly build of zlib anymore (ever since I ran into problems with it
years ago).

I suppose TortoiseSVN also does not use the assembly build of zlib.

--
Johan

[Daniel Sahlberg]

You are probably right. Thanks for clarifying!

@Tomasz Lubinski, can you try to use zlib without the assembly code?

Kind regards,

Daniel

[Nathan Hartman]

On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn <jco...@gmail.com> wrote:

<snip>

> > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski <t.lub...@verocel.pl>:
> >> Very strange problem with assembly code in zlib 1.2.11.

<snip>

> Indeed, zlib's assembly code seems to be unreliable on Windows. When I
> build / test (for signing new releases) on Windows, I never use the
> assembly build of zlib anymore (ever since I ran into problems with it
> years ago).

I thought we had that documented somewhere but I can't seem to find it
now. I remember reading a recommendation not to use the assembly build
of zlib because of various issues. It may have been in the mailing
list archives.

Compilers these days have gotten so good that I think it's a waste of
time to write hand-coded assembly unless there's a very specific and
very special use case requiring exact control over something. Data
structure and algorithm design make a far bigger impact than trying to
save a few cycles. :-)

Hope you get better results now!

Cheers,
Nathan

[Daniel Sahlberg]

Den fre 22 okt. 2021 07:30Tomasz Lubinski <t.lub...@verocel.pl> skrev:

I confirm, I used back zlib 1.2.11 but without ASMV, ASMIN symbols defined. Now it works correctly (even with OPENSSL 3.0).

Regards and thank you for your help,
Tomek L

Thanks for checking and confirming. I will try to dig out references and make sure it is documented in our build instructions! 

Kind regards 

Daniel Sahlberg 

-----Original Message-----
From: Nathan Hartman <hartman...@gmail.com>
Sent: Thursday, October 21, 2021 5:57 PM
To: Tomasz Lubinski <t.lub...@verocel.pl>
Cc: Subversion <us...@subversion.apache.org>; Johan Corveleyn <jco...@gmail.com>; Daniel Sahlberg <daniel.l...@gmail.com>
Subject: Re: Subversion 1.14.1 and serf 1.3.9

[Tomasz Lubinski]

I confirm, I used back zlib 1.2.11 but without ASMV, ASMIN symbols defined. Now it works correctly (even with OPENSSL 3.0).

Regards and thank you for your help,
Tomek L

-----Original Message-----
From: Nathan Hartman <hartman...@gmail.com>

Sent: Thursday, October 21, 2021 5:57 PM
To: Tomasz Lubinski <t.lub...@verocel.pl>

Cc: Subversion <us...@subversion.apache.org>; Johan Corveleyn <jco...@gmail.com>; Daniel Sahlberg <daniel.l...@gmail.com>

Subject: Re: Subversion 1.14.1 and serf 1.3.9

[Daniel Sahlberg]

Den tors 21 okt. 2021 kl 17:56 skrev Nathan Hartman <hartman...@gmail.com>:

On Thu, Oct 21, 2021 at 8:06 AM Johan Corveleyn <jco...@gmail.com> wrote:

<snip>

> > Den tors 21 okt. 2021 kl 13:39 skrev Tomasz Lubinski <t.lub...@verocel.pl>:
> >> Very strange problem with assembly code in zlib 1.2.11.

<snip>

> Indeed, zlib's assembly code seems to be unreliable on Windows. When I
> build / test (for signing new releases) on Windows, I never use the
> assembly build of zlib anymore (ever since I ran into problems with it
> years ago).

I thought we had that documented somewhere but I can't seem to find it
now. I remember reading a recommendation not to use the assembly build
of zlib because of various issues. It may have been in the mailing
list archives.

Following up a few loose threads from the discussion:

It was discussed in 2013 (the thread started a few months earlier but I picked a message with a clear suggestion): https://svn.haxx.se/dev/archive-2013-10/0109.shtml

I didn't search for any later discussion.

TortoiseSVN removed support for building the ASM versions in 2013 as a result of the above thread.

The Subversion build templates also removing the support for building the ASM code as of r1560864.

The code itself was removed from zlib develop branch on Oct 13th 2017, however no new release has been made since.

I have added a warning in INSTALL, see r1894491.

Thanks to everyone for the valuable input!

Kind regards

Daniel