bugGNU dbm - Bugs: bug #399, gdbm 1.15 fails Perl testsuite -...

 
 
Show feedback again

You are not allowed to post comments on this tracker with your current authentification level.

bug #399: gdbm 1.15 fails Perl testsuite - store problem isn't reported properly

Submitted by:  Marek Skalick√Ĺ <mskalick>
Submitted on:  Fri 29 Jun 2018 12:06:06 PM EEST  
 
Category: NonePriority: 5 - Normal
Severity: 8 - BlockerStatus: Fixed
Privacy: PublicAssigned to: Sergey Poznyakoff <gray>
Open/Closed: Closed

Tue 31 Jul 2018 12:43:50 AM EEST, comment #4:

Fixed in version 1.17

Sergey Poznyakoff <gray>
Project AdministratorIn charge of this item.
Tue 03 Jul 2018 11:21:39 PM EEST, comment #3:

Proposed changes to the GDBM_File module, taking into account recent improvements in the library: http://git.gnu.org.ua/cgit/gdbm/GDBM_File.git

Sergey Poznyakoff <gray>
Project AdministratorIn charge of this item.
Sun 01 Jul 2018 12:29:46 PM EEST, comment #2:

I pushed commit 030e685e. The gdbm_close function now returns int and sets both gdbm_errno and errno on error. Gdbm_sync has been changed accordingly.

Sergey Poznyakoff <gray>
Project AdministratorIn charge of this item.
Sat 30 Jun 2018 08:00:29 PM EEST, comment #1:

Hi Marek,

I would suppose this problem must have been observed well before 1.15. If fact, the fatal.t test supposes that a call to gdbm_store (or any modification to the database, for that matter) is immediately synched to disk. This is not true at least since version 1.9. In many cases gdbm_store does not result in disk writes and therefore is not able to detect I/O errors. That's the first point.

The second one: the gdbm_close function is indeed declared as void, as well as gdbm_synch. This is due to historic reasons. I agree this should be changed and will address this issue in the next release of gdbm.

Sergey Poznyakoff <gray>
Project AdministratorIn charge of this item.
Fri 29 Jun 2018 12:06:06 PM EEST, original submission:

Gdbm 1.15 (1.16 is also affected) changed behavior of reporting problems with database file.

The bug was discovered by perl ext/GDBM_File/t/fatal.t test. It is reported in perl bug tracker - https://rt.perl.org/Public/Bug/Display.html?id=133295#txn-1563420

In short, test actions are:
1) Perl test lets gdbm library to open a database file
2) then Perl closes a file descriptor gdbm uses for that database file
3) then Perl asks gdbm to store a key-value pair into the database
4) then Perl call gdbm_close()

The test tries to "simulate" I/O error. So old gdbm crashes in step 3) The new one finishes successfully although close() in step 4) fails with EBADF.

I know that this Perl test uses nonstandard procedure, but I/O errors could occur. And errors from msync()/fsync(), close(), flock(),... aren't currently checked, which could lead to unexpected behavior.

Or is described behavior expected? Is there any reason why gdbm_close() don't return any value?

Marek Skalick√Ĺ <mskalick>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by gray (Posted a comment)
  • -unavailable- added by mskalick (Submitted the item)
  • -unavailable- added by mskalick (Thanks in advance for reply if this is a bug or expected behavior.)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    5 latest changes follow.

    Date Changed By Updated Field Previous Value => Replaced By
    Tue 31 Jul 2018 12:43:50 AM EESTgrayOpen/ClosedOpen=>Closed
    Sun 01 Jul 2018 12:29:46 PM EESTgrayStatusIn Progress=>Fixed
    Sat 30 Jun 2018 08:00:29 PM EESTgrayStatusNone=>In Progress
      Assigned toNone=>gray
    Fri 29 Jun 2018 12:06:06 PM EESTmskalickCarbon-Copy-=>Added gray
    Show feedback again

    Back to the top


    Powered by Savane 3.1-cleanup+gray