You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by cm...@collab.net on 2001/08/27 16:23:31 UTC

Berkeley DB problems on Win98

Greeting, Sleepycat Support Folk.  C. Michael (Mike) Pilato here,
trying to get to the bottom of some problems I (and others) have been
seeing with Berkeley 3.2.9 and 3.3.1 on Windows 98.  I reported this
problem a while ago but was told that I didn't provide enough
information.  Well, I'm not sure I'll meet that requirement this time
around either, but I'm certainly going to try.  

What follows is the contents (or most of them) of two mails sent to
the Subversion developers list (by me) recently detailing my findings
to our community there.

--------------------------------------------------------------------------

From: cmpilato@collab.net
Subject:  Berkeley DB Win32 problems.
To: dev@subversion.tigris.org
Date: 22 Aug 2001 13:37:14 -0500
X-From-Line: dev-return-1217-cmpilato=collab.net@subversion.tigris.org  Wed Aug 22 16:36:14 2001
Return-Path: <de...@subversion.tigris.org>
Received: from localhost (IDENT:cmpilato@localhost [127.0.0.1])
	by collab.net (8.9.3/8.8.7) with ESMTP id QAA06061
	for <cm...@localhost>; Wed, 22 Aug 2001 16:36:13 -0500
Delivered-To: cmpilato@collab.net
Received: from laswell.sp.collab.net
	by localhost with POP3 (fetchmail-5.3.1)
	for cmpilato@localhost (single-drop); Wed, 22 Aug 2001 16:36:13 -0500 (CDT)
Received: (qmail 10669 invoked by uid 0); 22 Aug 2001 18:40:13 -0000
Received: from h35.sny.collab.net (HELO tigris.org) (64.208.42.45)
  by laswell.sp.collab.net with SMTP; 22 Aug 2001 18:40:13 -0000
Received: (qmail 2666 invoked by uid 204); 22 Aug 2001 18:40:08 -0000
Mailing-List: contact dev-help@subversion.tigris.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
list-help: <ma...@subversion.tigris.org>
list-unsubscribe: <ma...@subversion.tigris.org>
list-post: <ma...@subversion.tigris.org>
Delivered-To: mailing list dev@subversion.tigris.org
Received: (qmail 2651 invoked from network); 22 Aug 2001 18:40:07 -0000
Sender: cmpilato@collab.net
Message-ID: <x7...@pascal.ch.collab.net>
X-Mailer: Gnus v5.7/Emacs 20.5
X-UIDL: `WJ!!>I4!!NP-"!0]W!!
Lines: 129
Xref: pascal.ch.collab.net mail.collabnet.subversion:3159

Attached to this mail is a patch for one of the Sleepycat's C example
programs that, I think, demonstrates the problems we have with BDB
under Win98 (see Issue #384).  Can someone please apply the patch to
db-3.2.9/examples_c/ex_env.c and make sure I've not done anything
illegal with respect to how I'm using Berkeley's API?  If there are
no glaring errors in the code, I'd like to send it off to Sleepycat
with a kind "Whassup?" and see if we can nail this thing.

Note that in the patch, all I do differently is that I optionally pass
a DB_CREATE flag to db_env->open based on the non-zero-ness of the
'create' argument.  Their sample used to create a DB_ENV, close it,
then remove it.  With my patch, it is created, closed, and then an
attempt at re-opening it happens (which fails on my box with 'Resource
temporarily unavailable').  I'd love to hear how this behaves under
WinNT/2000, too.  See svn_fs_create_berkeley() and
svn_fs_open_berkeley() for our uses of BDB in this context.

Anybody with Win32 Memory Mapped I/O experience out there?  I have
none (but I'm learning).  It's really weird that I can see all this
data getting written to the __db.00x files through MMIO, but it never
seems to hit the disk.  Specifically, if I'm following the code right,
I'm seeing a DB_REGION In fact, I think that's the crux of the whole
problem.  If I recall correctly, when trying to re-open the
environment, BDB is looking for a 'magic number' in the __db.001 file
and not finding it.  I tried compiling a version of BDB with a call to
FlushViewOfFile() just before UnmapViewOfFile() but the behavior was
still the same.

Here is where the code is failing (os_win32/os_map.c:__os_map()) :

    if (is_region) {
        /*
         * XXX
         * Windows/95 zeroes anonymous memory regions at last close.
         * This means that the backing file can exist and reference
         * the region, but the region itself is no longer initialized.
         * If the caller is capable of creating the region, update
         * the REGINFO structure so that they do so.
         */
        renv = (REGENV *)pMemory;
        if (renv->magic == 0)
            if (F_ISSET(infop, REGION_CREATE_OK))
                F_SET(infop, REGION_CREATE);
            else {
                (void)UnmapViewOfFile(pMemory);
                pMemory = NULL;
                ret = EAGAIN;
            }
    }

We are trying to attach to a shared memory region, and renv->magic is
0 because the REGENV structure, which was the first thing written to
the region during the DB_ENV creation step, didn't persist (it was
never written to disk when db_env->close() was called after the
creation step).  However, because the REGION_CREATE_OK flag is not set
(which, I think is because the DB_CREATE flag wasn't passed in our
"re-open" call to db_env->open()), EAGAIN is returned up the stack,
which incidentally looks something like:

    __os_map()
    __os_r_sysattach()
    __os_r_attach()
    __db_e_attach()
    db_setup()
    main()

I'm pooped, so I won't be visiting this again until at least late
tonight, but perhaps much later.

Okay, here's the patch I mentioned waaaaaaaaay up there.

  <<< snip - I posted a bogus patch, so see this second mail >>>

--------------------------------------------------------------------------

From: cmpilato@collab.net
Subject:  Re: Berkeley DB Win32 problems.
To: dev@subversion.tigris.org
Date: 23 Aug 2001 11:17:36 -0500
X-From-Line: dev-return-1240-cmpilato=collab.net@subversion.tigris.org  Thu Aug 23 11:17:52 2001
Return-Path: <de...@subversion.tigris.org>
Received: from localhost (IDENT:cmpilato@localhost [127.0.0.1])
	by collab.net (8.9.3/8.8.7) with ESMTP id LAA12822
	for <cm...@localhost>; Thu, 23 Aug 2001 11:17:52 -0500
Delivered-To: cmpilato@collab.net
Received: from laswell.sp.collab.net
	by localhost with POP3 (fetchmail-5.3.1)
	for cmpilato@localhost (single-drop); Thu, 23 Aug 2001 11:17:52 -0500 (CDT)
Received: (qmail 10277 invoked by uid 0); 23 Aug 2001 16:16:53 -0000
Received: from h35.sny.collab.net (HELO tigris.org) (64.208.42.45)
  by laswell.sp.collab.net with SMTP; 23 Aug 2001 16:16:53 -0000
Received: (qmail 29565 invoked by uid 204); 23 Aug 2001 16:16:44 -0000
Mailing-List: contact dev-help@subversion.tigris.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
list-help: <ma...@subversion.tigris.org>
list-unsubscribe: <ma...@subversion.tigris.org>
list-post: <ma...@subversion.tigris.org>
Delivered-To: mailing list dev@subversion.tigris.org
Received: (qmail 29556 invoked from network); 23 Aug 2001 16:16:44 -0000
Sender: cmpilato@collab.net
References: <x7...@pascal.ch.collab.net>
In-Reply-To: cmpilato@collab.net's message of "22 Aug 2001 13:37:14 -0500"
Message-ID: <x7...@pascal.ch.collab.net>
X-Mailer: Gnus v5.7/Emacs 20.5
X-UIDL: !ES!!2W6"!I<O"!c[O!!
Lines: 60
Xref: pascal.ch.collab.net mail.collabnet.subversion:3187

cmpilato@collab.net writes:

> Attached to this mail is a patch for one of the Sleepycat's C example
> programs that, I think, demonstrates the problems we have with BDB
> under Win98 (see Issue #384).

Actually, what was attached to that mail was a broken patch.  Let me
try this again:

--- ex_env.c	Sat Oct 28 09:57:46 2000
+++ ex_env.c.new	Thu Aug 23 11:10:07 2001
@@ -37,7 +37,7 @@
 #endif
 #endif
 
-int	db_setup __P((char *, char *, FILE *, char *));
+int	db_setup __P((char *, char *, FILE *, char *, int));
 int	db_teardown __P((char *, char *, FILE *, char *));
 #ifdef HAVE_VXWORKS
 int	ex_env __P((void));
@@ -70,7 +70,11 @@
 	data_dir = CONFIG_DATA_DIR;
 
 	printf("Setup env\n");
-	if ((ret = db_setup(home, data_dir, stderr, progname)) != 0)
+	if ((ret = db_setup(home, data_dir, stderr, progname, 1)) != 0)
+		return (ret);
+
+	printf("Re-open env\n");
+	if ((ret = db_setup(home, data_dir, stderr, progname, 0)) != 0)
 		return (ret);
 
 	printf("Teardown env\n");
@@ -81,9 +85,10 @@
 }
 
 int
-db_setup(home, data_dir, errfp, progname)
+db_setup(home, data_dir, errfp, progname, create)
 	char *home, *data_dir, *progname;
 	FILE *errfp;
+    int create;
 {
 	DB_ENV *dbenv;
 	int ret;
@@ -122,7 +127,7 @@
 
 	/* Open the environment with full transactional support. */
 	if ((ret = dbenv->open(dbenv, home,
-    DB_CREATE | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_INIT_TXN,
+	    (create ? DB_CREATE : 0) | DB_INIT_LOCK | DB_INIT_LOG | DB_INIT_MPOOL | DB_INIT_TXN,
 	    0)) != 0) {
 		dbenv->err(dbenv, ret, "environment open: %s", home);
 		dbenv->close(dbenv, 0);


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: Berkeley DB problems on Win98 [#4511]

Posted by Sleepycat Software Support <su...@sleepycat.com>.
On Mon, Aug 27, 2001 at 11:23:31AM -0500, cmpilato@collab.net (cmpilato@collab.net) wrote:
> Greeting, Sleepycat Support Folk.  C. Michael (Mike) Pilato here,
> trying to get to the bottom of some problems I (and others) have been
> seeing with Berkeley 3.2.9 and 3.3.1 on Windows 98.  I reported this
> problem a while ago but was told that I didn't provide enough
> information.  Well, I'm not sure I'll meet that requirement this time
> around either, but I'm certainly going to try.  

Thank you for your email.  For future reference, your Support Request
number is #4511.  Unfortunately, the Sleepycat engineer who is best
versed in Windows 98 issues is out of the office this week, but I'll
make sure that he looks into your report when he gets back.

Regards,
David Krinsky
Sleepycat Software Support

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Sleepycat Software Inc.		support@sleepycat.com
				http://www.sleepycat.com

Please Note: as far as we know, you do not currently have a
support contract with Sleepycat Software, nor are you doing
product evaluation for potential commercial use, and so we can
only address the issues you have raised as time is available.
If we are incorrect in either respect, please let us know as
soon as possible.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org