You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Karl Fogel <kf...@galois.collab.net> on 2000/10/16 20:13:58 UTC
some APR brokenness, I think
It looks like there's some problem with how apr_day_snames[] and
apr_month_snames[] are getting declared now. They used to be arrays
of fixed-length strings -- each string was three letters and a
terminating null, such as "Mon", "Tue", "Wed", etc, and "Jan", "Feb",
"Mar", etc.
Now they are arrays of fixed-length strings whose every byte is
'\0'. This is probably not the change someone intended. :-)
I thought maybe I was corrupting memory somewhere, but it doesn't look
like it, because the arrays already toast as of entry to main(). Have
looked over recent changes to APR, but don't see anything offhand that
would be causing this.
Greg, can you take a look, or forward this report to whoever maintains
the time code? Thanks.
cd subversion/libsvn_wc/tests
gdb checkout-test
(gdb) break main
Breakpoint 6 at 0x8049566: file checkout-test.c, line 122.
(gdb) run checkout-1.delta foo_dir
[...]
Breakpoint 6, main (argc=3, argv=0xbffff984) at checkout-test.c:122
(gdb) p apr_day_snames
$34 = {"\000\000\000", "\000\000\000", "\000\000\000", "\000\000\000",
"\000\000\000", "\000\000\000", "\000\000\000"}
(gdb) p apr_month_snames
$35 = {"\000\000\000" <repeats 12 times>}
(gdb) quit
The program is running. Exit anyway? (y or n) y
Linux thread target has restored Unknown signal handling
Linux thread target has restored Unknown signal handling
Debugger finished
Re: M2 planning (was: Re: some APR brokenness, I think)
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Right. If the above set of features doesn't sound right (e.g. you want to
> throw property handling in :-), then we can adjust. Otherwise, I'll handle
> updates and simple commits (no copying or renaming of files/dirs yet).
Sounds good.
> Seems reasonable so far. I'll flesh out the TASKS/STACK file and see how
> that feels.
Thank you.
> Quite fine by me. As I mentioned before, I actually think that
> libsvn_ra_local could end up as a crutch during development if we aren't
> careful. ("I don't want to run Apache... just let me do my dev over this
> little local loop here"; oops.. there goes testing for our main code path)
My fear too.
> Lessee... three weeks starting November 1. I'm all up for declaring M2 to
> occur right before T-Day (somewhere in the 20th to 22nd) and then having
> people take a break.
Sounds good to me!
I'll write this all up somewhere permanent.
-K
M2 planning (was: Re: some APR brokenness, I think)
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Oct 17, 2000 at 05:49:14PM -0500, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
>...
> M1 got re-scheduled to this Friday, Oct 20th. I think we're doing
> okay for that, since we were mostly there already anyway. You should
> be able to hook up the networking code without disturbing or being
> disturbed by what's gone on elsewhere.
Okily dokily.
Since much of my focus is currently in mod_dav and mod_dav_svn, yes: it
should be pretty independent :-) Although I'll need the FS here soon...
>...
> > What's our due date? Or is at all in my lap? (urk!)
>
> How long do you think we need to hook up both client side and server
> side (i.e., actually start using Apache)?
Getting a "checkout" to happen will be quite easy, actually. I just reviewed
svn_fs.h and it looks like opening/reading files and dirs will be very
straightforward.
I'd say just another day or two of coding. (of course, something else will
need to *put* content into the repository)
Next: we have update and commit to handle. Commit must provide for adding
files/dirs, changing files, and deleting files/dirs. [for this round] This
will be another good chunk, but it should fit in the three weeks you mention
below.
> I'm trying to come up with a sequence of milestones, and estimate
> dates for them right now. Will get back to you on that. But rest
> assured that making m1 functionality happen over the wire is
> definitely the next milestone.
Right. If the above set of features doesn't sound right (e.g. you want to
throw property handling in :-), then we can adjust. Otherwise, I'll handle
updates and simple commits (no copying or renaming of files/dirs yet).
> If you think that will take longer than three weeks (of work, I mean,
> starting after you get back), then I'll have to reconsider some
> scheduling stuff. I'm guessing 3 weeks max, though, is that
> reasonable? (But please don't be afraid to send me bad news on a
> public list. :-) )
Seems reasonable so far. I'll flesh out the TASKS/STACK file and see how
that feels.
>...
> As I understand it, the whole point is that libsvn_ra_dav and
> libsvn_ra_local provide different implementations of the same
> interface (for those who are curious about the past discussion, the
> thread was "Subject: ra library -- philosophy").
Right.
> Now, what's in svn_ra.h might not be that interface yet (you mentioned
> that you threw it together quickly, although actually it looks pretty
> good to me).
Mostly, it is devoid of things like property handling, history reporting,
etc. All of that will need some kind of interface.
> But anyway, as long as we make sure that interface is
> not network-specific, implementing libsvn_ra_local is a task for the
> future -- just a matter of providing alternative functionality behind
> that interface.
>
> So I don't think we should spend time on libsvn_ra_local right now.
> Being truly networked, with Apache and the whole nine yards, is a
> higher priority, because that's what we need to replace CVS. The
> network code path is the one we must Get Right from the beginning.
> Let's concentrate on that.
Quite fine by me. As I mentioned before, I actually think that
libsvn_ra_local could end up as a crutch during development if we aren't
careful. ("I don't want to run Apache... just let me do my dev over this
little local loop here"; oops.. there goes testing for our main code path)
> It will be a fine day when we stop swapping these XML files back and
> forth and are actually sending DAV protocol over the wire. :-)
My mission in life! :-)
> So tasks are:
>
> - make sure you like the interface in svn_ra.h
> - make sure libsvn_ra_dav provides it
>
> Does that sound like a good place to start?,
The interface is fine with me. I just need to fill in the functions now. And
then the mod_dav and mod_dav_svn work.
Lessee... three weeks starting November 1. I'm all up for declaring M2 to
occur right before T-Day (somewhere in the 20th to 22nd) and then having
people take a break.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: some APR brokenness, I think
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> Next milestone? Did M1 become official? I thought there were some FS issues
> that held us back.
Well, there were some wc issues, that's for sure, such as the alloc
bug that Greg H nailed. :-)
M1 got re-scheduled to this Friday, Oct 20th. I think we're doing
okay for that, since we were mostly there already anyway. You should
be able to hook up the networking code without disturbing or being
disturbed by what's gone on elsewhere.
> No matter... networking is on my list, and I'll just code until its done :-)
> Also, Joe will contribute and/or keep me honest. I'm prepping mod_dav today,
> but will be returning to some SVN coding. The network troubles that I had
> last week have calmed down (albeit a slow link, but stable now), so I can
> actually get stuff done.
Glad to hear it.
> [ and an interesting note: mod_dav_svn actually loads and does something
> as of last week... ]
:-)
> What's our due date? Or is at all in my lap? (urk!)
How long do you think we need to hook up both client side and server
side (i.e., actually start using Apache)?
I'm trying to come up with a sequence of milestones, and estimate
dates for them right now. Will get back to you on that. But rest
assured that making m1 functionality happen over the wire is
definitely the next milestone.
If you think that will take longer than three weeks (of work, I mean,
starting after you get back), then I'll have to reconsider some
scheduling stuff. I'm guessing 3 weeks max, though, is that
reasonable? (But please don't be afraid to send me bad news on a
public list. :-) )
> libsvn_ra_local
>
> Establishing the formal RA interface would be a Good Thing (I can code
> against what is built for _local and/or tweak as network-specific things
> arise), and creating a proper layer between the front and back ends (linked
> via _local) would also be a win.
>
> In any case... how would you like to proceed, O Great Project Leader? I *am*
> still here for a few days. [I'll add stuff to TASKS/STACK as a starter]
Far be it from me to impose order on this herd of cats. :-)
But since you ask...
As I understand it, the whole point is that libsvn_ra_dav and
libsvn_ra_local provide different implementations of the same
interface (for those who are curious about the past discussion, the
thread was "Subject: ra library -- philosophy").
Now, what's in svn_ra.h might not be that interface yet (you mentioned
that you threw it together quickly, although actually it looks pretty
good to me). But anyway, as long as we make sure that interface is
not network-specific, implementing libsvn_ra_local is a task for the
future -- just a matter of providing alternative functionality behind
that interface.
So I don't think we should spend time on libsvn_ra_local right now.
Being truly networked, with Apache and the whole nine yards, is a
higher priority, because that's what we need to replace CVS. The
network code path is the one we must Get Right from the beginning.
Let's concentrate on that.
It will be a fine day when we stop swapping these XML files back and
forth and are actually sending DAV protocol over the wire. :-)
So tasks are:
- make sure you like the interface in svn_ra.h
- make sure libsvn_ra_dav provides it
Does that sound like a good place to start?,
-K
Re: some APR brokenness, I think
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Oct 17, 2000 at 04:51:10PM -0500, Karl Fogel wrote:
> Greg Stein <gs...@lyra.org> writes:
> > believe it would be nice to have a different forum. For example, I'm
> > leaving for London on Friday for ApacheCan + leisure. I'll be gone about
> > 10 days. I seriously doubt that I'm going to have any connectivity this
> > time around (unlike Aus). How do APR problems get fixed?
[ amend that: I'll probably have spotty access from Saturday thru Wednesday.
after that (Thu-Mon), all bets are off. ]
> Oh! Have fun!...
thx! I will. I plan to actually meet Joe, too. Should be fun... we've been
working together for two years now. Never spoken on the phone or met in
person. Kinda funny actually, how the net works :-)
> That affects Subversion's schedule (such as it is) a tiny bit. I had
> been hoping to make the next milestone be setting up networking, and
Next milestone? Did M1 become official? I thought there were some FS issues
that held us back.
No matter... networking is on my list, and I'll just code until its done :-)
Also, Joe will contribute and/or keep me honest. I'm prepping mod_dav today,
but will be returning to some SVN coding. The network troubles that I had
last week have calmed down (albeit a slow link, but stable now), so I can
actually get stuff done.
[ and an interesting note: mod_dav_svn actually loads and does something
as of last week... ]
> that it would start next Monday. If you're going to be gone, though,
> we'll just start on it the moment you get back (10 days later), and
What's our due date? Or is at all in my lap? (urk!)
> meanwhile there's *plenty* we can do with the documentation,
> libsvn_client, more fs work, etc, so no worries.
libsvn_ra_local
Establishing the formal RA interface would be a Good Thing (I can code
against what is built for _local and/or tweak as network-specific things
arise), and creating a proper layer between the front and back ends (linked
via _local) would also be a win.
In any case... how would you like to proceed, O Great Project Leader? I *am*
still here for a few days. [I'll add stuff to TASKS/STACK as a starter]
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: some APR brokenness, I think
Posted by Karl Fogel <kf...@galois.collab.net>.
Greg Stein <gs...@lyra.org> writes:
> believe it would be nice to have a different forum. For example, I'm
> leaving for London on Friday for ApacheCan + leisure. I'll be gone about
> 10 days. I seriously doubt that I'm going to have any connectivity this
> time around (unlike Aus). How do APR problems get fixed?
Oh! Have fun!...
That affects Subversion's schedule (such as it is) a tiny bit. I had
been hoping to make the next milestone be setting up networking, and
that it would start next Monday. If you're going to be gone, though,
we'll just start on it the moment you get back (10 days later), and
meanwhile there's *plenty* we can do with the documentation,
libsvn_client, more fs work, etc, so no worries.
No biggie, just want to sync up.
Re: some APR brokenness, I think
Posted by Greg Stein <gs...@lyra.org>.
On Mon, Oct 16, 2000 at 03:59:56PM -0500, Karl Fogel wrote:
> Karl Fogel <kf...@galois.collab.net> writes:
> > Greg, can you take a look, or forward this report to whoever maintains
> > the time code? Thanks.
>
> By the way, may I lobby once again for an APR-specific bug-reporting
"again" ? dang. Either I missed it the first time, or I dropped the ball...
> address to be mentioned somewhere in the APR documentation (i.e., a
> file at the top level of the APR tree)?
>
> I feel silly sending the reports to you personally, Greg, but also
> feel weird sending them as Apache bug reports. After all, if APR is
> truly a separable library, then this has nothing to do with Apache.
> So I send them to you. :-)
Well, several issues here.
*) I don't mind you sending them to me AT ALL. No problem. However, I do
believe it would be nice to have a different forum. For example, I'm
leaving for London on Friday for ApacheCan + leisure. I'll be gone about
10 days. I seriously doubt that I'm going to have any connectivity this
time around (unlike Aus). How do APR problems get fixed?
IOW, sending them here is fine, but various circumstances could affect
the response time.
*) While APR is *designed* to be separable from Apache, it was decided a
long time ago to not actually do it until after the Apache 2.0 release.
Primarly, this was done for logistical and ease-of-distro purposes. Much
like we're releasing APR with SVN itself, Apache wanted to do the same.
In addition, keeping it in the same CVS repository was a large win.
*) The Apache bug database has several problems (for people using it, and
the developers themselves). In addition, it is more focused on end-user
issues than "coding" type stuff that we find with APR.
So... my recommended forum is the new-httpd@apache.org mailing list itself.
It is not a problem for anybody to post problems there, as long as they
relate to *code*. (you will be chastised for httpd.conf config issues,
though :-) About the only warning is to clarify at the top of your email
that you are not subscribed to new-httpd and ask for a CC: of the response.
It has that stupid Reply-To munging that we (thankfully) got rid of here.
[ <rant hopeful-listener="brian"> it's totally bogus for issues like this...
how can somebody post a question and expect a reply if the default MUA
sends the reply to the Reply-To rather than the questioner? bogus in many
ways... </rant> ]
As a final backup to new-httpd is to send directly to rbb@apache.org (Ryan
Bloom) who could be considered the lead for APR.
But again: except for my travel, I'll handle any APR issue that comes in my
direction.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
Re: some APR brokenness, I think
Posted by Karl Fogel <kf...@galois.collab.net>.
Karl Fogel <kf...@galois.collab.net> writes:
> Greg, can you take a look, or forward this report to whoever maintains
> the time code? Thanks.
By the way, may I lobby once again for an APR-specific bug-reporting
address to be mentioned somewhere in the APR documentation (i.e., a
file at the top level of the APR tree)?
I feel silly sending the reports to you personally, Greg, but also
feel weird sending them as Apache bug reports. After all, if APR is
truly a separable library, then this has nothing to do with Apache.
So I send them to you. :-)
-K
> cd subversion/libsvn_wc/tests
> gdb checkout-test
>
> (gdb) break main
> Breakpoint 6 at 0x8049566: file checkout-test.c, line 122.
> (gdb) run checkout-1.delta foo_dir
> [...]
> Breakpoint 6, main (argc=3, argv=0xbffff984) at checkout-test.c:122
> (gdb) p apr_day_snames
> $34 = {"\000\000\000", "\000\000\000", "\000\000\000", "\000\000\000",
> "\000\000\000", "\000\000\000", "\000\000\000"}
> (gdb) p apr_month_snames
> $35 = {"\000\000\000" <repeats 12 times>}
> (gdb) quit
> The program is running. Exit anyway? (y or n) y
> Linux thread target has restored Unknown signal handling
> Linux thread target has restored Unknown signal handling
>
> Debugger finished
RE: some APR brokenness, I think
Posted by "William A. Rowe, Jr." <wr...@rowe-clan.net>.
I broke it ... I'm on it ... update in 20
Bill
> -----Original Message-----
> From: Greg Stein [mailto:gstein@lyra.org]
> Sent: Monday, October 16, 2000 10:33 PM
> To: kfogel@collab.net
> Cc: dev@subversion.tigris.org; wrowe@rowe-clan.net
> Subject: Re: some APR brokenness, I think
>
>
> I found the problem. In a recent revamping of how symbols are
> exported/imported from APR and the various Apache submodules,
> an "extern"
> was dropped off of the declarations of those variables in apr_time.h.
>
> I'll get it sorted out and fixed up. Tonite, or tomorrow at
> the latest. I
> saw your temporary "fix", so a delay until tomorrow seems allowable
> [ I'm also working on a mod_dav 1.0.2 release tonite ]
>
> Cheers,
> -g
>
> On Mon, Oct 16, 2000 at 03:13:58PM -0500, Karl Fogel wrote:
> > It looks like there's some problem with how apr_day_snames[] and
> > apr_month_snames[] are getting declared now. They used to be arrays
> > of fixed-length strings -- each string was three letters and a
> > terminating null, such as "Mon", "Tue", "Wed", etc, and
> "Jan", "Feb",
> > "Mar", etc.
> >
> > Now they are arrays of fixed-length strings whose every byte is
> > '\0'. This is probably not the change someone intended. :-)
> >
> > I thought maybe I was corrupting memory somewhere, but it
> doesn't look
> > like it, because the arrays already toast as of entry to
> main(). Have
> > looked over recent changes to APR, but don't see anything
> offhand that
> > would be causing this.
> >
> > Greg, can you take a look, or forward this report to
> whoever maintains
> > the time code? Thanks.
> >
> > cd subversion/libsvn_wc/tests
> > gdb checkout-test
> >
> > (gdb) break main
> > Breakpoint 6 at 0x8049566: file checkout-test.c, line 122.
> > (gdb) run checkout-1.delta foo_dir
> > [...]
> > Breakpoint 6, main (argc=3, argv=0xbffff984) at
> checkout-test.c:122
> > (gdb) p apr_day_snames
> > $34 = {"\000\000\000", "\000\000\000", "\000\000\000",
> "\000\000\000",
> > "\000\000\000", "\000\000\000", "\000\000\000"}
> > (gdb) p apr_month_snames
> > $35 = {"\000\000\000" <repeats 12 times>}
> > (gdb) quit
> > The program is running. Exit anyway? (y or n) y
> > Linux thread target has restored Unknown signal handling
> > Linux thread target has restored Unknown signal handling
> >
> > Debugger finished
>
> --
> Greg Stein, http://www.lyra.org/
>
Re: some APR brokenness, I think
Posted by Greg Stein <gs...@lyra.org>.
I found the problem. In a recent revamping of how symbols are
exported/imported from APR and the various Apache submodules, an "extern"
was dropped off of the declarations of those variables in apr_time.h.
I'll get it sorted out and fixed up. Tonite, or tomorrow at the latest. I
saw your temporary "fix", so a delay until tomorrow seems allowable
[ I'm also working on a mod_dav 1.0.2 release tonite ]
Cheers,
-g
On Mon, Oct 16, 2000 at 03:13:58PM -0500, Karl Fogel wrote:
> It looks like there's some problem with how apr_day_snames[] and
> apr_month_snames[] are getting declared now. They used to be arrays
> of fixed-length strings -- each string was three letters and a
> terminating null, such as "Mon", "Tue", "Wed", etc, and "Jan", "Feb",
> "Mar", etc.
>
> Now they are arrays of fixed-length strings whose every byte is
> '\0'. This is probably not the change someone intended. :-)
>
> I thought maybe I was corrupting memory somewhere, but it doesn't look
> like it, because the arrays already toast as of entry to main(). Have
> looked over recent changes to APR, but don't see anything offhand that
> would be causing this.
>
> Greg, can you take a look, or forward this report to whoever maintains
> the time code? Thanks.
>
> cd subversion/libsvn_wc/tests
> gdb checkout-test
>
> (gdb) break main
> Breakpoint 6 at 0x8049566: file checkout-test.c, line 122.
> (gdb) run checkout-1.delta foo_dir
> [...]
> Breakpoint 6, main (argc=3, argv=0xbffff984) at checkout-test.c:122
> (gdb) p apr_day_snames
> $34 = {"\000\000\000", "\000\000\000", "\000\000\000", "\000\000\000",
> "\000\000\000", "\000\000\000", "\000\000\000"}
> (gdb) p apr_month_snames
> $35 = {"\000\000\000" <repeats 12 times>}
> (gdb) quit
> The program is running. Exit anyway? (y or n) y
> Linux thread target has restored Unknown signal handling
> Linux thread target has restored Unknown signal handling
>
> Debugger finished
--
Greg Stein, http://www.lyra.org/