/usr/include/stropts.h

It appears that in FC9 and above that stropts.h has been removed

My previous attempts in FC7 have successed but I do receive warnings like

Quote

fattach is not implemented and will always fail

What kind of changes should I make to npipe.cpp to safely remove dependancies on stropts.h?

Interestingly, I found the same problem arising in the Ingres Database project.

Thanks

Robbie

I made the following changes to npipe.cpp and it seemed to compile (conquestlinux1414)

20a21
> #include <sys/ioctl.h>
22c23
< #include <stropts.h>
---
> //#include <stropts.h>
139c140,141
< 	if(fattach(itsControlWriteFd, itsName))
---
> 	//if(fattach(itsControlWriteFd, itsName))
> 	if (0)
161c163,164
< 	if(ioctl(itsControlWriteFd, I_PUSH, "connld"))
---
> 	//if(ioctl(itsControlWriteFd, I_PUSH, "connld"))
> 	if(0)
279c282,283
< 		if(ioctl(itsControlReadFd, I_RECVFD, &itsConnectionFd))
---
> 		//if(ioctl(itsControlReadFd, I_RECVFD, &itsConnectionFd))
> 		if (0) 
297c301,302
< 		if(!isastream(itsConnectionFd))
---
> 		//if(!isastream(itsConnectionFd))
> 		if (1)

I seem to be only able to rebuild 200,000 images before I get the following error.

Quote

Thu Nov 6 19:38:20 2008 [Regen] /storage/NMUS_Data/dicom/1367206_AE_IT/1.2.840.113663.1500.1.12335.1.99.20040922.162032.203/1.2.528.1.1001.100.3.645.1577.21021204110.20041017024916578/1.2.528.1.1001.100.4.645.1577.20021204110.20043017024916625.dcm -SUCCESS
Thu Nov 6 19:39:18 2008 ***VR:ReAlloc out of memory allocating 242380800 bytes
Thu Nov 6 19:39:18 2008 ***A fatal error occurred (out of memory) - closing server

I try

Quote

./dgate --regendir:MAG0,1367206_AE_IT

and it seems to be ok.

Is there a way to get around what looks to be a memory leak problem?

Thanks

I've been tracking the memory usage of dgate and it seems to have a stable low-water mark at 7Mb. It does spike up to 200Mb when regenerating some files.

It may be that the computer doesn't have enough RAM. It is an old laptop with 256Mb RAM and 256Mb Swapspace. I installed FC9 without Gnome or KDE.

I tried the following script

./dgate --debuglog_in:debug.log
./dgate --debuglevel:4
./dgate --log_on:normal.log
find . -maxdepth 1 -mindepth 1 -type d -exec /usr/loca/src/conquest/dgate --regendir:MAG0,{} \;

I've also figured out a way to get the dgate server process to restart if it dies.

I managed to rebuild 600,000 images before postgres reported out of memory errors. Will need to investigate expanding swapspace.

I am pleased to report that I managed to successfully rebuild using the following config:

Quote

Compaq Laptop Evo N800v
Intel P4 Mobile 1.7Ghz
256 Mb RAM
2Gb Swap partition
Linux FC9 kernel 2.6.26
PostgreSQL 8.3.5
conquestlinux 1414

Display More

DICOM data is stored over two NAS devices using "FileNameSyntax = 8". The NAS is mounted using the cifs filesystem driver
There are about 1700000 images in 2TB and the rebuild took about 3 days.

./dgate --debuglog_in:debug.log
./dgate --debuglevel:4
./dgate --log_on:normal.log
find . -maxdepth 1 -mindepth 1 -type d -exec /usr/loca/src/conquest/dgate --regendir:MAG0,{} \;

This is just a note that the Fedora patch indicated at the top of this post is still required for Conquest version 1.4.15.