cygwin 1.7.15: svn disk I/O error

[Rolf Campbell]

Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
but I can't say for sure. The nature of these errors are as follows:

$ svn up
Updating '.':
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file


$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'


Sometimes the errors happen, sometimes not. It seems to be about 50% of
the time svn has this type of error now. I've tried running the exact
same version of SVN (the command-line version shipped with TourtoiseSVN)
on the exact same working copies and I don't have any errors.

I'm not running any anti-virus (I was, but I uninstalled it a couple of
days ago to make sure it wasn't causing this trouble).

[Christopher Faylor]

Post by Rolf Campbell
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
$ svn up
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
Sometimes the errors happen, sometimes not. It seems to be about 50% of
the time svn has this type of error now. I've tried running the exact
same version of SVN (the command-line version shipped with TourtoiseSVN)
on the exact same working copies and I don't have any errors.
I'm not running any anti-virus (I was, but I uninstalled it a couple of
days ago to make sure it wasn't causing this trouble).

Why would you think that a disk I/O error was either anti-virus or Cygwin
related and not... a disk I/O error? Have you looked in your event logs
for errors?

cgf

[Rolf Campbell]

Post by Christopher Faylor

Post by Rolf Campbell
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
Sometimes the errors happen, sometimes not. It seems to be about 50% of
the time svn has this type of error now. I've tried running the exact
same version of SVN (the command-line version shipped with TourtoiseSVN)
on the exact same working copies and I don't have any errors.
I'm not running any anti-virus (I was, but I uninstalled it a couple of
days ago to make sure it wasn't causing this trouble).

Why would you think that a disk I/O error was either anti-virus or Cygwin
related and not... a disk I/O error? Have you looked in your event logs
for errors?
cgf

I thought it might be anti-virus related because I read another message
about someone having a similar problem and he thought it might be
anti-virus related. But now I can't find where I was reading that
message anymore.

Anyway, another reason is because I only experience this error when I
use the cygwin version of SVN. Other versions do not run into any
errors when accessing the exact same working copies.

I just checked my event logs and I don't see any system errors related
to I/O. The only error today is about failing to start the PBADRV service.

[Garrison, Jim (ETW)]

-----Original Message-----
Subject: Re: cygwin 1.7.15: svn disk I/O error

Post by Rolf Campbell
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
$ svn up
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
Sometimes the errors happen, sometimes not. It seems to be about 50%
of the time svn has this type of error now. I've tried running the
exact same version of SVN (the command-line version shipped with
TourtoiseSVN) on the exact same working copies and I don't have any

errors.

Post by Rolf Campbell
I'm not running any anti-virus (I was, but I uninstalled it a couple of
days ago to make sure it wasn't causing this trouble).

Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?

It is indeed AV related -- a race between SQLite and AV

http://mail-archives.apache.org/mod_mbox/subversion-users/201204.mbox/%***@DEFTHW99E54MSX.ww902.siemens.net%3E

I just ran into this and got around it by temporarily disabling AV

[Garrison, Jim (ETW)]

-----Original Message-----
Subject: RE: cygwin 1.7.15: svn disk I/O error

-----Original Message-----
Subject: Re: cygwin 1.7.15: svn disk I/O error

Post by Rolf Campbell
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to
1.7.15, but I can't say for sure. The nature of these errors are as
$ svn up
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
Sometimes the errors happen, sometimes not. It seems to be about 50%
of the time svn has this type of error now. I've tried running the
exact same version of SVN (the command-line version shipped with
TourtoiseSVN) on the exact same working copies and I don't have any

errors.

Post by Rolf Campbell
I'm not running any anti-virus (I was, but I uninstalled it a couple
of days ago to make sure it wasn't causing this trouble).

Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?

It is indeed AV related -- a race between SQLite and AV
http://mail-archives.apache.org/mod_mbox/subversion-
4MSX.ww902.siemens.net%3E
I just ran into this and got around it by temporarily disabling AV

See also this thread
http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=4061&dsMessageId=2906294

[Warren Young]

Post by Garrison, Jim (ETW)

Post by Christopher Faylor
Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?

It is indeed AV related -- a race between SQLite and AV

That's one possibility, but check this out:

http://stackoverflow.com/questions/11007024/

tl;dr: someone made the problem go away by rolling my recent 3.7.12
release back to the prior 3.7.3 version.

I doubt the problem is in the upstream changes between .3 and .12. I'm
more worried about the build option changes. SQLite has a lot of
Windows-specific code in it, plus some Cygwin-specific code, too. The
build changes override some things to force it to believe it's being
built for a more generic POSIX type system.

It may be both things: the build option changes that force more I/O
calls to go through Cygwin instead of direct to the Win32 API could be
tickling BLODA bugs.

Yet another possibility is that the build option changes cause a subtle
ABI change that will be fixed when SVN is rebuilt against it.

[Rolf Campbell]

Post by Warren Young

Post by Garrison, Jim (ETW)

Post by Christopher Faylor
Why would you think that a disk I/O error was either anti-virus or
Cygwin related and not... a disk I/O error? Have you looked in your
event logs for errors?

It is indeed AV related -- a race between SQLite and AV

http://stackoverflow.com/questions/11007024/
tl;dr: someone made the problem go away by rolling my recent 3.7.12
release back to the prior 3.7.3 version.
I doubt the problem is in the upstream changes between .3 and .12. I'm
more worried about the build option changes. SQLite has a lot of
Windows-specific code in it, plus some Cygwin-specific code, too. The
build changes override some things to force it to believe it's being
built for a more generic POSIX type system.
It may be both things: the build option changes that force more I/O
calls to go through Cygwin instead of direct to the Win32 API could be
tickling BLODA bugs.
Yet another possibility is that the build option changes cause a subtle
ABI change that will be fixed when SVN is rebuilt against it.

Also, I don't think I'm running any A/V software (Windows keeps nagging
me that my system is *not* running A/V). I uninstalled it to see if
that was the problem before reporting it to this list.

Also#2: I'm seeing this problem on a Win7x64 machine, but I also have a
WinXPx32 machine which has started exhibiting the same symptoms. That
one *is* running Symantec A/V (which I've never had trouble with
before). It's a work machine, and I don't have permissions to uninstall
A/V, but I'll see if I can convince the IT guy to uninstall it for a
while to see if that resolves the problem.

[Rolf Campbell]

Post by Warren Young

Post by Garrison, Jim (ETW)
It is indeed AV related -- a race between SQLite and AV

http://stackoverflow.com/questions/11007024/
tl;dr: someone made the problem go away by rolling my recent 3.7.12
release back to the prior 3.7.3 version.
I doubt the problem is in the upstream changes between .3 and .12. I'm
more worried about the build option changes. SQLite has a lot of
Windows-specific code in it, plus some Cygwin-specific code, too. The
build changes override some things to force it to believe it's being
built for a more generic POSIX type system.
It may be both things: the build option changes that force more I/O
calls to go through Cygwin instead of direct to the Win32 API could be
tickling BLODA bugs.
Yet another possibility is that the build option changes cause a subtle
ABI change that will be fixed when SVN is rebuilt against it.

I've rolled my machine back to to .3 and I'll see if it fixes my system
too. Unfortunately, I'm not able to reproduce the problem *at all* this
morning with any version of anything. I guess I'll wait and see for now.

[Adam Dinwoodie]

Post by Rolf Campbell
Recently, I've noticed cygwin svn getting a LOT of errors during
operations. I think this started when upgrading from 1.7.14 to 1.7.15,
$ svn up
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
<snip>

I've had the same problem, and have found a solution: this appears for me to be an interaction with TortoiseSVN, which I have on my machine and which is entirely unaware of Cygwin.

Disabling TortoiseSVN's icon cache has completely resolved the issue for me. You can do this by running TortoiseSVN's Settings program, going to "Icon Overlays", and selecting "None" under "Status cache", then hitting Apply.

That may explain why Rolf's been hitting this despite apparently having no AV installed.

Adam

[Rolf Campbell]

Post by Adam Dinwoodie

Post by Rolf Campbell
$ svn up
svn: E200030: disk I/O error, executing statement 'RELEASE s6'
svn: E200030: sqlite: unable to open database file
svn: E200030: sqlite: unable to open database file
$ svn cleanup
svn: E200030: disk I/O error, executing statement 'RELEASE s79'
<snip>

I've had the same problem, and have found a solution: this appears for me to be an interaction with TortoiseSVN, which I have on my machine and which is entirely unaware of Cygwin.
Disabling TortoiseSVN's icon cache has completely resolved the issue for me. You can do this by running TortoiseSVN's Settings program, going to "Icon Overlays", and selecting "None" under "Status cache", then hitting Apply.
That may explain why Rolf's been hitting this despite apparently having no AV installed.
Adam

That's a very interesting discovery. I certainly am using TortoiseSVN.
There must be some interaction between the most recent version of
sqlite and TortoiseSVN's status scanner. I've been playing around with
sqlite versions and I've confirmed what others have stated that it's
only a problem with v3.7.12.1 and NOT a problem with v3.7.3.

I've upgraded back to v3.7.12.1 and disabled TortoiseSVN's icon scanner.
It appears to resolve the problem for me as well.

I would hate to add TortoiseSVN to the BLODA.

[Achim Gratz]

Post by Rolf Campbell
I would hate to add TortoiseSVN to the BLODA.

The icon cache _is_ dodgy — at least the one for TortoiseGit, which
needs to be restarted regularly.

But getting back to SQLite, backing out the changes in the build would
get us back a different bug. So it would be very interesting if you
could debug where it hits that roadblock in svn. I suspect that svn
does not deal with the file being locked exclusively (when TortoiseSVN
accesses the database) and some call through the windows interface
blocked. Note that SQLite isn't really designed for concurrent access
to the database file from a different process.


Regards,
Achim.

[Warren Young]

Post by Achim Gratz
I suspect that svn
does not deal with the file being locked exclusively (when TortoiseSVN
accesses the database) and some call through the windows interface
blocked.

It's possible svn has a timer on the call that results in a SQL call
through SQLite, and when this doesn't return as fast as svn thinks it
ought to, it bombs out, complaining that there "must" be a disk I/O
problem. What may actually be happening is that Windows' aggressive
locking strategy has set up a deadlock between two processes.

As for why .3 and .12 behave differently, it's probably because one or
more locks that used to be owned by the SQLite DLL that are now owned by
the Cygwin DLL. That is, files are being accessed on the DLL's behalf
by Cygwin now, rather than directly through the Windows API. Since
Cygwin doubtless does file I/O differently than SQLite did, for the same
basic reason that any two programmers tend to write code differently,
there's a new conflict.

If this is the case, the best solution may be for TortoiseSVN to stop
grabbing files for long-term exclusive use. It should only be locking
the svn DB files as long as is necessary to make some change.

Post by Achim Gratz
Note that SQLite isn't really designed for concurrent access
to the database file from a different process.

There is a paucity of truth in that statement. See the SQLite FAQ:

https://sqlite.org/faq.html#q5

But, there's only so much SQLite can do to cooperate with the OS's
locking strategy. On POSIX systems where SQLite was born, locking is
mostly advisory and cooperative, whereas Windows gives you mandatory
locks by default in a lot of cases. Mandatory locks allow one process
(e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to
change a file, indefinitely.

[Achim Gratz]

Post by Warren Young

Post by Achim Gratz
Note that SQLite isn't really designed for concurrent access
to the database file from a different process.

There is a paucity of truth in that statement.

So let me re-formulate that sentence: concurrent access ultimately
relies on the file locking provided by the OS. The concurrency support
in SQLite is simply to not keep state outside a critical section and
lock the database file exclusively when entering one.

Post by Warren Young
But, there's only so much SQLite can do to cooperate with the OS's
locking strategy. On POSIX systems where SQLite was born, locking is
mostly advisory and cooperative, whereas Windows gives you mandatory
locks by default in a lot of cases. Mandatory locks allow one process
(e.g. TortoiseSVN) to deny another (e.g. Cygwin svn) the ability to
change a file, indefinitely.

Cygwin should (and apparently does) abstract away that difference. But
it seems that the locking strategy might be slightly different between
Win32 and POSIX, triggering a foray into that "disk I/O error" branch.
There may still be a bug some place else, i.e. it may get a timeout
rather than a "file locked" state. I'll have a look when I find some
time.


Regards,
Achim.

[Achim Gratz]

Post by Achim Gratz
Cygwin should (and apparently does) abstract away that difference. But
it seems that the locking strategy might be slightly different between
Win32 and POSIX, triggering a foray into that "disk I/O error" branch.
There may still be a bug some place else, i.e. it may get a timeout
rather than a "file locked" state. I'll have a look when I find some
time.

I've had a look at the sources and those two error messages are with
near certainty generated by SQLite. Unfortunately there are many places
where they could be generated, it would certainly help if it could be
traced where exactly in SQLite this is happening (must be at least two
places, maybe more).

I've tried to re-build svn against the new SQLite library, but I'm not
sure if that works correctly on my machine (the tests are still runnning
and I get some test failures already since apparently I'm still missing
some dependencies). However, I don't have TortoiseSVN installed anyway.

David Rothenberger, I'd appreciate if you could try to do another build
of svn and tell us if there are any test regressions w.r.t to your last
build.


Regards,
Achim.

[David Rothenberger]

Post by Achim Gratz
I've tried to re-build svn against the new SQLite library, but I'm not
sure if that works correctly on my machine (the tests are still runnning
and I get some test failures already since apparently I'm still missing
some dependencies). However, I don't have TortoiseSVN installed anyway.

The cygport file should check for all required build dependencies. If
you find one missing, please let me know.

Post by Achim Gratz
David Rothenberger, I'd appreciate if you could try to do another build
of svn and tell us if there are any test regressions w.r.t to your last
build.

The point of the rebuild is to see if building against the latest
sqlite3 package fixes the problem? I can do a rebuild in the next few
days. However, I have not been able to get the test suite to run fully
for quite a while due to rebase problems. Many tests use triggers and
these often encounter fork failures. I have never seen a SQLite error
message in the test failures, but I also don't have TortoiseSVN
installed. (I removed it long ago when the icon cache caused me problems.)

I'm not sure that me running the test suite will prove much, so I'll
make the rebuild available as a test release in case someone that was
experiencing the problem would like to try it out.
--
David Rothenberger ---- ***@acm.org

"Daddy, Daddy, make
Santa Claus go away!"
"I can't, son;
he's grown too
powerful."
"HO HO HO!"
-- Duck's Breath Mystery Theatre

[Achim Gratz]

Post by David Rothenberger
The cygport file should check for all required build dependencies. If
you find one missing, please let me know.

I'm not near my work machine, so this is from memory... the test suite
requires perl modules I didn't have installed and fails most perl tests
without them — not too worried about this, will install those later this
week. Also, the requires check for Berkeley-DB 4.2 and 4.5, but only
4.5 and 4.8 are currently offered by Cygwin. I've had to comment out
the Apache module build since the mod_dav.la was nowhere to be found and
no Cygwin package provides it.

Post by David Rothenberger

Post by Achim Gratz
David Rothenberger, I'd appreciate if you could try to do another build
of svn and tell us if there are any test regressions w.r.t to your last
build.

The point of the rebuild is to see if building against the latest
sqlite3 package fixes the problem?

Either that or maybe whether the testsuite that comes with svn confirms
the problem and thus delivers a debuggable testcase.

Post by David Rothenberger
I can do a rebuild in the next few days. However, I have not been able
to get the test suite to run fully for quite a while due to rebase
problems.

The ephemeral rebase option I posted patches for in cygwin-apps should
help with that. Since I should have the same problem, I'll see that I
can adapt the cygport file to use it.

Post by David Rothenberger
Many tests use triggers and these often encounter fork
failures. I have never seen a SQLite error message in the test
failures, but I also don't have TortoiseSVN installed. (I removed it
long ago when the icon cache caused me problems.)

If you still have a test log it might prove helpful.

Post by David Rothenberger
I'm not sure that me running the test suite will prove much, so I'll
make the rebuild available as a test release in case someone that was
experiencing the problem would like to try it out.

Thanks, that should help as well if the OP could check if it makes any
difference.


Regards,
Achim.

[Adam Dinwoodie]

Post by Achim Gratz

Post by David Rothenberger
I'm not sure that me running the test suite will prove much, so I'll
make the rebuild available as a test release in case someone that was
experiencing the problem would like to try it out.

Thanks, that should help as well if the OP could check if it makes any
difference.

I'm hitting the same problem (or, at least, my setup is similar to the OP's,
and the thing that fixed it for me also fixed it for him), I'm certainly
willing to test any new build.

Adam

[Achim Gratz]

Post by Achim Gratz
I'm not near my work machine, so this is from memory... the test suite
requires perl modules I didn't have installed and fails most perl tests
without them — not too worried about this, will install those later this
week.

The fail is not due to a module missing, but due to the perl dynaloader not
being able to load the DLL produced by the build. The error message is not
helpful as there's no reason given for why it couldn't load the DLL. The file
exists and is readable /executable. However, LDD gives strange output:

# ldd subversion/bindings/swig/perl/native/blib/arch/auto/SVN/_Core/_Core.dll
ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x772e0000)
kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x75c60000)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll (0x756b0000)
??? => ??? (0x587f0000)
??? => ??? (0x6c540000)
??? => ??? (0x61000000)
??? => ??? (0x6b1a0000)
??? => ??? (0x615e0000)
??? => ??? (0x61ad0000)
??? => ??? (0x617d0000)
??? => ??? (0x619a0000)
??? => ??? (0x617e0000)
??? => ??? (0x6c520000)
??? => ??? (0x6be20000)
??? => ??? (0x6b6a0000)
??? => ??? (0x66620000)
??? => ??? (0x65030000)
??? => ??? (0x64ca0000)
??? => ??? (0x60560000)
??? => ??? (0x61bf0000)
??? => ??? (0x75590000)
??? => ??? (0x771d0000)
??? => ??? (0x754a0000)

Post by Achim Gratz
I've had to comment out the Apache module build since the mod_dav.la
was nowhere to be found and no Cygwin package provides it.

Even with the changes to the build config by Yaakov trying to build the Apache
module fails for me, now with unresolved symbols of the form "_dav_*". I've
built without mod_dav to work around that.

Post by Achim Gratz
The ephemeral rebase option I posted patches for in cygwin-apps should
help with that. Since I should have the same problem, I'll see that I
can adapt the cygport file to use it.

Rebasing does help. Failing Perl tests aside (which never start due to the
issue outlined above), all further tests so far are pass. Judging from the
current progress, I'd think tests will run at least for two more hours.


Regards,
Achim.

[David Rothenberger]

Post by Achim Gratz

Post by Achim Gratz
I'm not near my work machine, so this is from memory... the test suite
requires perl modules I didn't have installed and fails most perl tests
without them — not too worried about this, will install those later this
week.

The fail is not due to a module missing, but due to the perl dynaloader not
being able to load the DLL produced by the build. The error message is not
helpful as there's no reason given for why it couldn't load the DLL. The file

Strange. It works for me and the ldd output for _Core.dll is reasonable.

Post by Achim Gratz

Post by Achim Gratz
I've had to comment out the Apache module build since the mod_dav.la
was nowhere to be found and no Cygwin package provides it.

Even with the changes to the build config by Yaakov trying to build the Apache
module fails for me, now with unresolved symbols of the form "_dav_*". I've
built without mod_dav to work around that.

Yaakov's changes worked for me.

Post by Achim Gratz
Rebasing does help. Failing Perl tests aside (which never start due to the
issue outlined above), all further tests so far are pass. Judging from the
current progress, I'd think tests will run at least for two more hours.

Yes, rebasing helped for me, too. The Ruby tests encountered fork
failures, but everything else is working.

I don't think this proves much, though. The errors I was getting in the
past were fork failures and not the SQLite error being reported.

Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.

[Achim Gratz]

Post by David Rothenberger
Strange. It works for me and the ldd output for _Core.dll is reasonable.

What version of autotools, swig etc. are you using? The only swig
wrappers that work for me are those for Python. Both Ruby and Perl seem
to die on those strangely non-functional DLL the build has produced.
Ruby had an additional problem: it was looking for the libraries in a
directory .ext, but the build put them into .libs. A symlinked fixed
that, but then the DLL could not be loaded anyway...

Post by David Rothenberger
Yaakov's changes worked for me.

Yes, there must be some difference in how the build got configured.
Anyway, it seems that your new build will be available much faster than
any attempt by me to find and fix those differences.

Post by David Rothenberger
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.

Thank you.


Regards,
Achim.

[Achim Gratz]

Post by David Rothenberger
Strange. It works for me and the ldd output for _Core.dll is reasonable.

I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting the ldd output for
your _Core.dll?

Post by David Rothenberger
Yaakov's changes worked for me.

I was still missing a -devel package. Once installed, the Apache modules build
and, more importantly link.

Regards,
Achim.

[David Rothenberger]

Post by Achim Gratz

Post by David Rothenberger
Strange. It works for me and the ldd output for _Core.dll is reasonable.

I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting the ldd output for
your _Core.dll?

% ldd /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/SVN/_Core/_Core.dll
ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x772f0000)
kernel32.dll => /c/Windows/syswow64/kernel32.dll (0x74ae0000)
KERNELBASE.dll => /c/Windows/syswow64/KERNELBASE.dll (0x74c80000)
cygapr-1-0.dll => /usr/bin/cygapr-1-0.dll (0x6e8c0000)
cygwin1.dll => /usr/bin/cygwin1.dll (0x61000000)
cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x6d6b0000)
cyguuid-1.dll => /usr/bin/cyguuid-1.dll (0x67a40000)
cygssp-0.dll => /usr/bin/cygssp-0.dll (0x67f40000)
cygsvn_swig_perl-1-0.dll => /usr/bin/cygsvn_swig_perl-1-0.dll (0x67c40000)
cygsvn_delta-1-0.dll => /usr/bin/cygsvn_delta-1-0.dll (0x67e10000)
cygsvn_subr-1-0.dll => /usr/bin/cygsvn_subr-1-0.dll (0x67c50000)
cygaprutil-1-0.dll => /usr/bin/cygaprutil-1-0.dll (0x6e8a0000)
cygcrypt-0.dll => /usr/bin/cygcrypt-0.dll (0x6e3e0000)
cygexpat-1.dll => /usr/bin/cygexpat-1.dll (0x6da30000)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x69a90000)
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x699a0000)
cygmagic-1.dll => /usr/bin/cygmagic-1.dll (0x69530000)
cygz.dll => /usr/bin/cygz.dll (0x67650000)
cygsqlite3-0.dll => /usr/bin/cygsqlite3-0.dll (0x68030000)
CRYPT32.DLL => /c/Windows/syswow64/CRYPT32.DLL (0x76740000)
msvcrt.dll => /c/Windows/syswow64/msvcrt.dll (0x76860000)
MSASN1.dll => /c/Windows/syswow64/MSASN1.dll (0x74cd0000)
cygperl5_10.dll => /usr/bin/cygperl5_10.dll (0x689f0000)
cygsvn_diff-1-0.dll => /usr/bin/cygsvn_diff-1-0.dll (0x67df0000)
??? => ??? (0x770000)

Post by Achim Gratz

Post by David Rothenberger
Yaakov's changes worked for me.

I was still missing a -devel package. Once installed, the Apache modules build
and, more importantly link.

Which -devel package was missing? cygport should have warned you
about missing build dependencies.

[Achim Gratz]

Post by David Rothenberger

Post by Achim Gratz
I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting the ldd output for
your _Core.dll?

% ldd /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/SVN/_Core/_Core.dll
ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x772f0000)

[...]

Post by David Rothenberger
cygsvn_diff-1-0.dll => /usr/bin/cygsvn_diff-1-0.dll (0x67df0000)
??? => ??? (0x770000)

Hmm. This is an installed version of the same library, not the one from
the build directory... note also that I build for Perl 5.14 in case that
makes a difference. Looking at the addresses from my library I know
where cygwin1.dll is and it is already in a different place. I could
look up all the other libraries in the rebase database to find what they
are. I have no idea what the unresolved addresses above 0x70000000 are
and I see you also have one of these, so maybe this is normal. Anyway,
I still don't know when and why ldd decides to show you "???" and if
that relates to the problem with DynaLoader.

Any way, I think those "???" are a red herring, I've built on my home
machine and there it works, even though I have those "???" entries as
well (albeit in total much less lines, but this is a Win7/64 machine
vs. Win7/32bit at work and perl 5.10).

Post by David Rothenberger

Post by Achim Gratz
I was still missing a -devel package. Once installed, the Apache modules build
and, more importantly link.

Which -devel package was missing? cygport should have warned you
about missing build dependencies.

I updated some other packages (libserf) as well, so I don't know which
one it was exactly, but I think it might have been openldap-devel.
Interestingly enough it was the linking step that failed, not the
compilation, so the header files must already have been present via some
other package.

Gnome-keyring requires pkg-config during the configure step, not
requested by the cygport file.

Ruby tests are still failing because it looks for the extension
libraries in a different directory than where they really are.


Regards,
Achim.

[David Rothenberger]

Post by Achim Gratz

Post by David Rothenberger

Post by Achim Gratz
I can't seem to get this working. There are a few warnings, but nothing that
would explain such a massive fail. Would you mind posting the ldd output for
your _Core.dll?

% ldd /usr/lib/perl5/vendor_perl/5.10/i686-cygwin/auto/SVN/_Core/_Core.dll
ntdll.dll => /c/Windows/SysWOW64/ntdll.dll (0x772f0000)

[...]

Post by David Rothenberger
cygsvn_diff-1-0.dll => /usr/bin/cygsvn_diff-1-0.dll (0x67df0000)
??? => ??? (0x770000)

Hmm. This is an installed version of the same library, not the one from
the build directory

That's correct. I've cleaned up my build directory. I did try it from my
build directory before, though, and there were no ???.

Post by Achim Gratz
... note also that I build for Perl 5.14 in case that
makes a difference.

I make two packages, one for 5.10 and one for 5.14. There's a separate
patch that's required for 5.14. Did you include it? The source package
for -4 includes it automatically.

Post by Achim Gratz
Any way, I think those "???" are a red herring, I've built on my home
machine and there it works, even though I have those "???" entries as
well (albeit in total much less lines, but this is a Win7/64 machine
vs. Win7/32bit at work and perl 5.10).

The perl bindings work for me on Win7/64 using 5.10. I use them every day.

Post by Achim Gratz

Post by David Rothenberger

Post by Achim Gratz
I was still missing a -devel package. Once installed, the Apache modules build
and, more importantly link.

Which -devel package was missing? cygport should have warned you
about missing build dependencies.

I updated some other packages (libserf) as well, so I don't know which
one it was exactly, but I think it might have been openldap-devel.
Interestingly enough it was the linking step that failed, not the
compilation, so the header files must already have been present via some
other package.

There was a problem with the openldap-devel package at one point; it was
missing lots of things. I had to reinstall it to get the libraries.

Post by Achim Gratz
Gnome-keyring requires pkg-config during the configure step, not
requested by the cygport file.

Thanks, I'll add that to the .cygport file.

Post by Achim Gratz
Ruby tests are still failing because it looks for the extension
libraries in a different directory than where they really are.

The tests work for me, but I've never been able to get them to work
without first installing the newly built packages. The last time I did
this, I did:

1. Do "cygport *.cygport almostall"
2. Install the packages.
3. Rebase the dll and so files in */build and */inst
4. Do "cygport *.cygport check"

All the tests passed except for a Ruby test (it appeared the output came
in a different order than expected) and a few Perl tests (it couldn't
delete a temporary directory).

[Achim Gratz]

Post by David Rothenberger
I make two packages, one for 5.10 and one for 5.14. There's a separate
patch that's required for 5.14. Did you include it? The source package
for -4 includes it automatically.

Yes, I worked from the -4 package on one machine and the -3 package on
the other.

Post by David Rothenberger
There was a problem with the openldap-devel package at one point; it was
missing lots of things. I had to reinstall it to get the libraries.

Then it was almost certainly this package, which is properly requested
by the .cygport file.

Post by David Rothenberger
The tests work for me, but I've never been able to get them to work
without first installing the newly built packages. The last time I did
1. Do "cygport *.cygport almostall"
2. Install the packages.
3. Rebase the dll and so files in */build and */inst
4. Do "cygport *.cygport check"
All the tests passed except for a Ruby test (it appeared the output came
in a different order than expected) and a few Perl tests (it couldn't
delete a temporary directory).

Ah OK, I tried to do the tests without those packages installed. Thanks.


Regards,
Achim.

[Achim Gratz]

Post by David Rothenberger
The tests work for me, but I've never been able to get them to work
without first installing the newly built packages.

After some more investigations, this is because the dynamic linker seems to use
the libraries installed on the system rather than the ones in the build
directory at least sometimes during the tests and if they are either not present
or from a different version of svn things are falling apart. If I find a way to
have it always use the newly built libraries instead (or at least the ones
installed in $DESTDIR) I'll send a patch.


Regards,
Achim.

[marco atzeri]

Post by Achim Gratz

Post by David Rothenberger
The tests work for me, but I've never been able to get them to work
without first installing the newly built packages.

After some more investigations, this is because the dynamic linker seems to use
the libraries installed on the system rather than the ones in the build
directory at least sometimes during the tests and if they are either not present
or from a different version of svn things are falling apart. If I find a way to
have it always use the newly built libraries instead (or at least the ones
installed in $DESTDIR) I'll send a patch.
Regards,
Achim.

a solution for testing is to add the new directory as first in the PATH.

[Achim Gratz]

Post by marco atzeri
a solution for testing is to add the new directory as first in the PATH.

I think it already tries to do that, I'll have to check more closely if it's
missing some directories or if the order is perhaps wrong. It may also be that
the Ruby and Perl dynaloaders ignore the PATH settings in certain situations (at
least the Perl dynaloader seems to map the library via an absolute path).

It will be a while before I get to this, for now I'll just use the workaround of
installing the untested libraries onto the build system before testing.


Regards,
Achim.

[marco atzeri]

Post by Achim Gratz

Post by marco atzeri
a solution for testing is to add the new directory as first in the PATH.

I think it already tries to do that, I'll have to check more closely if it's
missing some directories or if the order is perhaps wrong. It may also be that
the Ruby and Perl dynaloaders ignore the PATH settings in certain situations (at
least the Perl dynaloader seems to map the library via an absolute path).
It will be a while before I get to this, for now I'll just use the workaround of
installing the untested libraries onto the build system before testing.
Regards,
Achim.

if it is a perl dll, than he need to install.
In windows the current directory is always considered so the perl
binary will use the dll in /usr/bin before anything else in the PATH.

I have the same issue testing the perl-Graphics-Magick package

Regards
Marco

[Rolf Campbell]

Post by David Rothenberger
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.

I just upgraded to the -5 package, and turned the TSVN icon caching back
on, and it very quickly failed in the same way as the -3 package.

[Achim Gratz]

Post by Rolf Campbell

Post by David Rothenberger
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.

I just upgraded to the -5 package, and turned the TSVN icon caching
back on, and it very quickly failed in the same way as the -3 package.

:-(

Now, if somebody could find out _where_ in SQLite it fails...


Regards,
Achim.

[Warren Young]

Post by Achim Gratz

Post by Rolf Campbell

Post by David Rothenberger
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.

I just upgraded to the -5 package, and turned the TSVN icon caching
back on, and it very quickly failed in the same way as the -3 package.

:-(
Now, if somebody could find out _where_ in SQLite it fails...

Is it not true that you're the only one in many years of SQLite's
availability in Cygwin who wanted it compiled the way it currently is?
Since everyone else was apparently happy with it the way it was, and the
new way is causing problems, I'd say it's up to you to find the fix
before I give up and release the next version with the compilation
changes reverted.

Put another way: I have two parties of users, both of whom claim SQLite
is giving them problems, one a group of size=1, and the other group
somewhat larger.

[Achim Gratz]

Post by Warren Young

Post by Achim Gratz
Now, if somebody could find out _where_ in SQLite it fails...

Is it not true that you're the only one in many years of SQLite's
availability in Cygwin who wanted it compiled the way it currently is?

Well yes, since one couldn't use temporary databases unless you have
administrator rights. There may be a fix of this going through the
Win32 interfaces as it were, but if there is, it's not easily spottable.

Post by Warren Young
Since everyone else was apparently happy with it the way it was, and
the new way is causing problems, I'd say it's up to you to find the
fix before I give up and release the next version with the compilation
changes reverted.

This is what I expect you to do and hence the frowny — yet another
package that I have to locally patch. I can't easily test this myself
since I don't have TortoiseSVN installed and as I said there's too many
places where the error messages could come from, so I'm still hoping
that someone can point to where exactly it's croaking in interaction
with TortoiseSVN.

Post by Warren Young
Put another way: I have two parties of users, both of whom claim
SQLite is giving them problems, one a group of size=1, and the other
group somewhat larger.

I understand.


Regards,
Achim.

[Warren Young]

Post by Achim Gratz
I can't easily test this myself
since I don't have TortoiseSVN installed

Me, too, but it seems to me that there's a better way to find the
problem than trying to replicate the problem reporters' exact
environment. That's too complicated. The leading hypothesis explaining
the problem is that there's a file locking problem between two programs
both trying to access the same set of SQLite DB files. So, write two
programs to do exactly that, and see if they will fight over the DB file
or not.

If they cooperate, as the SQLite FAQ says they should, then we're off in
the weeds and someone needs to come up with a better hypothesis.

If they fight, you then have two simple programs that, together,
demonstrate the problem, which means you're much closer to finding a
real fix that makes both sets of users happy.

Take advantage of the fact that I'm a disinterested Cygwin package
maintainer. You have some time to play with here.

[David Rothenberger]

Post by Rolf Campbell

Post by David Rothenberger
Anyway, I'll have a new release available shortly built against the
latest SQLite package, so others that want to use TortoiseSVN can try it.

I just upgraded to the -5 package, and turned the TSVN icon caching back
on, and it very quickly failed in the same way as the -3 package.

I'm sorry this isn't working for you, but as Subversion packager for
Cygwin, I'm not planning to spend any time figuring out why. I have had
problems with TortoiseSVN's icon cache and Cygwin Subversion for years
and just came to the conclusion it had to be turned off.

There is a reasonable work-around, tracking this down appears to be a
lot of work, and I personally don't care. Sorry if that sounds rude; I
just don't have the time, interest, or skills to work on this further.

I'll be glad to do anything to help someone else track it down or
include a patch to fix it.