Bug #1012
open
dcmqrscp's index.dat file size "explodes"
Added by Marco Eichelberg almost 4 years ago.
Updated over 3 years ago.
Category:
Library and Apps
Description
It has been observed that the size of the "index.dat" index file maintained by dcmqrscp suddenly massively increases, from a few 100 kBytes to a size of several GBytes. This seems to happen only when multiple clients send images (possibly the same image) in parallel, in different associations handled by different processes, which indicates some race situation not properly prevented by the file locking mechanisms used by dcmqrscp. The resulting index.dat file is a "sparse file" i.e. it allocates much fewer blocks than the file size seems to indicate. This means that some process seems to fseek() to some very high index value (far beyond the end of file) and then to write to that position. The bug has been observed with DCMTK 3.6.5, but is probably much older.
Files
|
index_dat_sparse.tar (900 KB)
index_dat_sparse.tar |
Sparse index file sample. Note that the uncompressed tar file is less than 1 MByte, while the index.dat shows a file size of 8 GBytes. |
Marco Eichelberg, 2021-10-26 16:43
|
|
- Target version changed from 3.6.7 to 3.7.1+
So far I have been unable to reproduce the problem in a debug setting. The only place where a sparse file could be created is DB_IdxAdd() (dcmqrscp/libsrc/dcmqrdbi.cc), where a seek operation followed by a write operation is performed. This would create a sparse file if the value of *idx is too large. However, it is unclear how this should happen since *idx is computed in the same function by iteratively reading through the entire file, and read(2) does not read past the end of the file. Furthermore, the index file is properly locked using an exclusive flock() during the execution of DB_IdxAdd() (I have tested this), and the file descriptor used is opened in the process executing DB_IdxAdd(), and not shared between processes.
Also available in: Atom
PDF
Updated by 
Updated by