Re: GNUnet-0.8.0c dies with assertion failures

jayjwa <[email protected]> Mon, 28 Sep 2009 12:46:49 -0400
Newsgroups gmane.network.gnunet.bugs
Message-ID <[email protected]>

On Thu, 24 Sep 2009, Christian Grothoff wrote:

> On Wednesday 23 September 2009 02:47:29 jayjwa wrote:
>> The gnunet daemon always dies with the following assertion errors:
>>
>> Sep 22 20:23:09 FATAL: Internal error: assertion failed at mysql.c:427.
>> zsh: abort      gnunetd -u daemon -d
>>
>> The gnunetd logfiles fill with these messages, but no other info.
>
> Hmm.  That should happen if the DB contains an entry that is corrupted in a
> particular way (and the code fails to test for it "nicely").  The following
> patch (also now in SVN HEAD) should fix this:
>
> sh-4.0$ svn diff mysql.c
> Index: mysql.c
> ===================================================================
> --- mysql.c     (revision 9006)
> +++ mysql.c     (working copy)
> @@ -418,6 +418,11 @@
>   contentSize = *(unsigned int *) result[0].buffer;
>   if (contentSize < sizeof (GNUNET_DatastoreValue))
>     return NULL;                /* error */
> +  if (contentSize > GNUNET_MAX_BUFFER_SIZE)
> +    {
> +       GNUNET_GE_BREAK (NULL, 0); /* far too big */
> +       return NULL;
> +    }
>   contentSize -= sizeof (GNUNET_DatastoreValue);
>   type = *(unsigned int *) result[1].buffer;
>   prio = *(unsigned int *) result[2].buffer;
>
>
> Alternatively you could drop the GNUnet database and recreate (but that's
> obviously not a good solution and would not prevent this from happening
> again).  With the above patch, you'll still get a warning printed whenever
> this corrupt DB entry is hit (but no more crashes).

Before getting this reply, I tried the drop database solution and that seems 
to have worked. I just deleted it and then recreated it the same again. It was 
originally made on an older MySQL back when I had an older version. Perhaps 
there's something different about the new version. I'll try the patch as well.



>> Running the test suite also ends similarly:
>>
>> Sep 22 20:20:57 `lt_dlopenext' failed for library
>> `libgnunetmodule_transport' with error: file not found
>> Sep 22 20:20:57 Internal error: assertion failed at handler.c:840.
>> /bin/sh: line 4: 13511 Aborted                 ${dir}$tst
>> FAIL: identitytest
>> ===================================
>> 1 of 1 tests failed
>> Please report to [email protected]
>> ===================================
>>
>> Which is odd because that file does exist at
>> /usr/lib/GNUnet/libgnunetmodule_transport.so
>
>
> That's a completely different error.  You need to set "GNUNET_PREFIX=/usr"
> before running the testsuite and then this crash should disappear.  Without
> this environment variable, the code does not look in "/usr" and fails to find
> the plugin.
>

I thought I set it, but it's quite possible I didn't.


>> Since then, I've updated to the most recent versions of MySQL and
>>  libmicrohttp and recompiled GNUnet. The problems still presists. The
>>  database server appears fine - I can login as the GNUnet user, work with
>>  the gnunet database, etc.
>>
>> As a side note, I tried to sign up for bug tracking to better follow this
>> issue, but there appears to be errors there too. I enter the confirmation
>>  URL, click 'update account' after supplying the requested info, and I only
>>  get the follow:
>>
>>
>> This account is protected. You are not allowed to access this until the
>> account protection is lifted.
>>
>> Please use the "Back" button in your web browser to return to the previous
>> page. There you can correct whatever problems were identified in this error
>> or select another action. You can also click an option from the menu bar to
>> go directly to a new section.
>
> Strange, I can see your account but it is not marked as "protected".  I've
> clicked the button for resetting your password.  If that does not help, please
> contact me off-list and maybe we can figure it out.

It seems to be fixed now, thanks.


>> Since I have no other way to send this, I'm using [email protected].
>
> No problem, thanks for your report!  Let me know if the above patch does not
> fix the problem.

Since the database recreation fixed it for the moment, the patch probably 
won't get a chance to work, but I'll apply it and see if anything further 
happens.