Segmentation fault after regendir

Tego · Oct 25th 2008

OS: CentOS5
Conquest 1.4.14

I often get a segmentation fault resulting in dgate crashing after I do the following (testing dgate commands).

1.) Copy patient directory into a temp folder (or from MAG0 into MAG1).
2.) Delete the patient ( ./dgate --deletepatient:12345).
3.) Copy the saved directory back into MAG0.
4.) Regen just the restored dir: (./dgate --regendir:MAG0,12345).

This is not 100 percent repeatable but happens very often. It appears dgate crashes after the regen is complete (as noted
by the serverlog. It doesn't appear to be time related (I've waited 5 minutes between the delete and regen calls).
If I get any more clues I'll post.

Thanks!
Tego

Tego · Oct 25th 2008

More testing:

OS: Linux - Centos (x86)
Conquest: 1.4.14
MySql: mysql Ver 14.12 Distrib 5.0.45

Testing using the default DB (DBASE III) doesn't seem to crash (or hasn't in my testing). I'll continue researching this
and start looking at code to see if I can get more clues. I'll continue testing with the default DB in additon to MySql and report
when i have additional information/progress.

Also, I'm starting some documentation on "dgate comand usage examples" that I hope will help others too.

Tego

marcelvanherk · Oct 26th 2008

Hi,

running dgate from GDB allows you to see where dgate crashes with "bt". With this info I can fix the problem.

Marcel

markpearson · Oct 27th 2008

I have found that --deleteseries causes a segfault with mysql but not dbase that might be a related problem. I am not explicitly running gdb but the output is quite informative.

Code

DGATE (1.4.14, build Mon Sep 15 10:20:12 2008) is running as threaded server
Server command sent using DGATE -- option
Deleting series: 1.2.840.113704.1.111.4464.1222827333.8
Query On Image
Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta
Values: DICOMSeries.SeriesInst = '1.2.840.113704.1.111.4464.1222827333.8' and DICOMSeries.SeriesInst = '1.2.840.113704.1.111.4464.1222827333.8' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
Tables: DICOMImages, DICOMSeries, DICOMStudies
Records = 76
*** glibc detected *** ./dgate: double free or corruption (fasttop): 0x08441ca0 ***
======= Backtrace: =========
/lib/tls/i686/cmov/libc.so.6[0xb7b2fa85]
/lib/tls/i686/cmov/libc.so.6(cfree+0x90)[0xb7b334f0]
/usr/lib/libstdc++.so.6(_ZdlPv+0x21)[0xb7cfab11]
./dgate(_Z12QueryOnImageP15DICOMDataObjectP5ArrayIS0_E+0x1f28)[0x80d9a74]
./dgate(_Z14RemoveFromPACSP15DICOMDataObjectj+0x3de)[0x80dd702]
./dgate(_Z12DeleteSeriesPcj+0x1be)[0x80de954]
./dgate(_ZN10StorageApp11ServerChildEi+0x2a41)[0x80effeb]
./dgate(_ZN9DriverApp17ServerChildThreadEi+0x1c)[0x806cf40]
./dgate(_Z12DriverHelperPv+0x31)[0x806cf79]
/lib/tls/i686/cmov/libpthread.so.0[0xb7f1c4fb]
/lib/tls/i686/cmov/libc.so.6(clone+0x5e)[0xb7b9ae5e]
======= Memory map: ========
08048000-0811b000 r-xp 00000000 08:11 36000308   /home/markp/disk2/imaging/dicom/conquest/mysql/dgate
0811b000-0811d000 rw-p 000d3000 08:11 36000308   /home/markp/disk2/imaging/dicom/conquest/mysql/dgate
0811d000-0858c000 rw-p 0811d000 00:00 0          [heap]
b7100000-b7121000 rw-p b7100000 00:00 0
b7121000-b7200000 ---p b7121000 00:00 0
b7216000-b7217000 ---p b7216000 00:00 0
b7217000-b7a64000 rw-p b7217000 00:00 0
b7a64000-b7a78000 r-xp 00000000 08:02 42507911   /usr/lib/libz.so.1.2.3.3
b7a78000-b7a79000 rw-p 00013000 08:02 42507911   /usr/lib/libz.so.1.2.3.3
b7a79000-b7a7a000 rw-p b7a79000 00:00 0
b7a7a000-b7a8e000 r-xp 00000000 08:02 92400732   /lib/tls/i686/cmov/libnsl-2.7.so
b7a8e000-b7a90000 rw-p 00013000 08:02 92400732   /lib/tls/i686/cmov/libnsl-2.7.so
b7a90000-b7a92000 rw-p b7a90000 00:00 0
b7a92000-b7a9b000 r-xp 00000000 08:02 92399899   /lib/tls/i686/cmov/libcrypt-2.7.so
b7a9b000-b7a9d000 rw-p 00008000 08:02 92399899   /lib/tls/i686/cmov/libcrypt-2.7.so
b7a9d000-b7ac4000 rw-p b7a9d000 00:00 0
b7ac4000-b7c0d000 r-xp 00000000 08:02 92386968   /lib/tls/i686/cmov/libc-2.7.so
b7c0d000-b7c0e000 r--p 00149000 08:02 92386968   /lib/tls/i686/cmov/libc-2.7.so
b7c0e000-b7c10000 rw-p 0014a000 08:02 92386968   /lib/tls/i686/cmov/libc-2.7.so
b7c10000-b7c13000 rw-p b7c10000 00:00 0
b7c13000-b7c1d000 r-xp 00000000 08:02 100852758  /lib/libgcc_s.so.1
b7c1d000-b7c1e000 rw-p 0000a000 08:02 100852758  /lib/libgcc_s.so.1
b7c1e000-b7c41000 r-xp 00000000 08:02 92400722   /lib/tls/i686/cmov/libm-2.7.so
b7c41000-b7c43000 rw-p 00023000 08:02 92400722   /lib/tls/i686/cmov/libm-2.7.so
b7c43000-b7d2b000 r-xp 00000000 08:02 42099264   /usr/lib/libstdc++.so.6.0.9
b7d2b000-b7d2e000 r--p 000e8000 08:02 42099264   /usr/lib/libstdc++.so.6.0.9
b7d2e000-b7d30000 rw-p 000eb000 08:02 42099264   /usr/lib/libstdc++.so.6.0.9
b7d30000-b7d37000 rw-p b7d30000 00:00 0
b7d37000-b7ed3000 r-xp 00000000 08:02 42134893   /usr/lib/libmysqlclient.so.15.0.0
b7ed3000-b7f16000 rw-p 0019b000 08:02 42134893   /usr/lib/libmysqlclient.so.15.0.0
b7f16000-b7f17000 rw-p b7f16000 00:00 0
b7f17000-b7f2b000 r-xp 00000000 08:02 92595395   /lib/tls/i686/cmov/libpthread-2.7.so
b7f2b000-b7f2d000 rw-p 00013000 08:02 92595395   /lib/tls/i686/cmov/libpthread-2.7.so
b7f2d000-b7f2f000 rw-p b7f2d000 00:00 0
b7f39000-b7f42000 r-xp 00000000 08:02 92400759   /lib/tls/i686/cmov/libnss_files-2.7.so
b7f42000-b7f44000 rw-p 00008000 08:02 92400759   /lib/tls/i686/cmov/libnss_files-2.7.so
b7f44000-b7f47000 rw-p b7f44000 00:00 0
b7f47000-b7f48000 r-xp b7f47000 00:00 0          [vdso]
b7f48000-b7f62000 r-xp 00000000 08:02 100852763  /lib/ld-2.7.so
b7f62000-b7f64000 rw-p 00019000 08:02 100852763  /lib/ld-2.7.so
bff79000-bff8e000 rw-p bffeb000 00:00 0          [stack]
Aborted

Display More

I also tried it on a series containing only 1 image with similar results.

marcelvanherk · Oct 27th 2008

Hi,

would you mind testing the SqLite database for these errors as well?

Marcel

markpearson · Oct 28th 2008

I can confirm that sqlite, mysql and postgresql all produce similar error output (at different memory locations). So the error is coming from the common codebase.

marcelvanherk · Oct 28th 2008

Thanks,

that helps in searching.

Marcel

Tego · Oct 28th 2008

I found some clues that I hope will help (not fully up to date on the code yet).
My testing to this point is only with MySQL and dbase. Only MySQL crashes and only
after deleting a patient followed by a "regendir" while dgate is running.

clue 1: When dgate is stopped after deleting the patient then restarted the "regendir" call does NOT crash dgate.
clue 2: The function Database::NextRecord is where the crash happens:

Code snippet from odbci.cpp:

for(i=0;i<ncolumns;i++)

{

if(row[i]) //Steini 20050507

switch (CTypeCodes[i])

{

case SQL_C_CHAR:

strcpy((char *)(vPtrs[i]),row[i]);

*LengthNeededs[i] = lengths[i]; // strlen(row[i]);

break;

When the above code is executed AFTER deleting a patient and then restarting dgate followed by
a "regendir" the array item row[i] (i=0) is NULL and the strcpy((char *)vPtrs[i]),row[i])) is NOT executed.
NOTE: vPtrs[0] has a NULL pointer at this point.

However, when a deletepatient is immediately followed by a "regendir", the array item "row[0]" has a value
and strcpy((char *(vPtrs[i],row[i]) is called with a NULL pointer in vPtrs[0]. This crashes dgate ( vPtrs[0]=NULL).

I wont have time to work on this more for several days but I assume the deletepatient call should be cleaning some params that are initialized to a known state on program startup.

Hope this is helpful and I'll continue with more debugging when I get back.

Thanks,

Tego

marcelvanherk · Oct 28th 2008

Hi Tego,

from where was the crashing function Database::NextRecord called? I am not able to reproduce the error with SqLite, so it is difficult for me to debug it.

Marcel

Tego · Oct 28th 2008

Hello Marcel

Quote

You wrote <snip>
from where was the crashing function Database::NextRecord called? I am not able to reproduce the error with SqLite

Sorry I have only tested with dbase III and MySql.

However, I just tried with sqLite and it doesn't seem to have the same problem ( regendir after deletepatient ).

Therefore the "deletepatient, followed by a regendir" ONLY crashes in MY testing when I use MySQL.
I will test further using sqLite to ensure that I just didn't get lucky.

For the bug that I was seeing, I recompiled with "debug flags" and backtraced from the segmenation fault (using gdb
and "ddd" for debugging). When I isolated the segmenation fault (in the code listed previously) I set breakpoints and tested using
the following method:

NOTES:
A.) The code snippet in my previous post is called in each of my three tests below.
B.) THIS crash occurs in MySql and not with dbase III or sqLite (this code is only included when compiled for MySQL).
C.) In tests 1 and 2 below, "row[0]" is NULL and the strcpy function is NOT called (vPtr[0]=NULL in all 3 tests).
However, in the 3 below, "row[0]" has a value and the strcpy is called with vPtr[0]=NULL (which causes the segmentation
fault.

TESTING:
1.) Test repeating "regendir" command WITHOUT deleting the patient .

Result: No crash.

2.) Delete patient, stop and restart dgate then do a "regendir".

Result: No crash.

3.) Delete patient, immediatly followed by a "regendir".

Result: Segmentation fault caused by strcpy to NULL pointer.
ENDTESTING:

I didn't follow the function calls into this code, just found where the code was crashing and looked for the cause
( strcpy to NULL pointer).

I WILL study the code as soon as I can so I can actually understand what I'm debugging and see if I can find the root cause.
Also, I will try and debug the crash that "markperson" noted too ( deleteseries) I have hopes they are all related.

Thanks,
Tego

marcelvanherk · Oct 28th 2008

Hi,

I really appreciate your debug efforts: they are very helpful.

I believe that ncolumns may be wrong, but only if I know where the function is called from, I can know what it should be (0?) and what it actually is. In any case the problem may originate from loops like this in the delete code (in dbsql.cpp):

Code

if (aDB.Query(WorkListTableName, "DICOMWorkList.PatientID", QueryString, NULL))			        {				 aDB.BindField (1, SQL_C_CHAR, Dum, 255, &sdword);				while (aDB.NextRecord())					aDB.DeleteRecord(WorkListTableName, DeleteString);			        }

The DeleteRecord call may affect the ncolumns variable use by Nextrecord. To test an easy possible fix, use a separate DB for DeleteRecord:

Code

bDB.DeleteRecord(WorkListTableName, DeleteString);

bDB would have to be opened with the usual passwords etc.

Addition: Or you can remove the line:

Code

return NewDeleteFromDB(DDO, DB);

in RemoveFromWorld (dbsql.cpp). This would enable alternative code. If that fixes the crash, we have localized it.

Marcel

Tego · Oct 30th 2008

Hi Marcel,

Quote

I removed return NewDeleteFromDB(DDO, DB); from dbsql.cpp and the crash still happens

Following is a back trace from the original code (note the back trace from the modified code shows the same -- except for memory locations changed by the recompile ).

#9 0x0804e36d in DriverHelper () at dgate.cpp:10445
#8 0x0804e334 in Driverapp::ServerChildThread () at dgate.cpp:10420
#7 0x080c5ea8 in StorageApp::ServerChild () at dgate.cpp:12455
#6 0x0809b84b in Regen () at regen.cpp:505
#5 0x0809b680 in RegenDir () at regen.cpp:296
#4 0x0809b3d5 in RegenToDatabase () at regen.cpp:135
#3 0x0809b0be in SaveToDataBase () at dbsql.cpp:858
#2 0x08099b8b in UpdateOrAddToTable () at dbsql.cpp:1314
#1 0x080912f2 in Database::NextRecord () at dbsql.cpp:1314
#0 0x00552b93 in strcpy () from libc.s0.6

Currently, I have a test that fails 100 % of the time. I have one patient in the database (I can send the data if that would help). I start dgate (dgate -v), then delete the patient ( ../dgate --deletepatient:23284) and then immediately follow with a regendir ( ./dgate --regendir:MAG0,23284).

The same test works fine with sqLite and dbase III.
I'm sorry I'm not more help. I REALLY need to read through the code before I can be useful.

Tego

marcelvanherk · Oct 31st 2008

Tego,

can you printf row[i] and particularly variable ncolums in routine NextRecord() that crashes? You can use OperatorConsole.printf to put it into the log. It may also help to give a debug log of both operations.

I tried to apt-get mysql and it drives me crazy. After hours of downloading using various debian mirrors, I still can't get mysql to install (I use an old Knoppix installed to HD that works fine except for that). So I cannot debug the code yet, bacuse the same sequence you list does not crash with MySQL under windows.

Marcel

Tego · Oct 31st 2008

Marcel,
Following is a print out:

1.) First is a printout when the dgate starts with the single patient in MAG0: (This gives a base starting point).
./dgate -v -r
i=0,ncolumns=14,row[0]=1.2.392.200036.9125.2.1767268739.64567296987.17566
i=1,ncolumns=14,row[1]=20081020
i=2,ncolumns=14,row[2]=161627.000
i=3,ncolumns=14,row[i]=NULL
i=4,ncolumns=14,row[i]=NULL
i=5,ncolumns=14,row[i]=NULL
i=6,ncolumns=14,row[i]=NULL
i=7,ncolumns=14,row[i]=NULL
i=8,ncolumns=14,row[i]=NULL
i=9,ncolumns=14,row[9]=CR
i=10,ncolumns=14,row[10]=xxxxx
i=11,ncolumns=14,row[i]=NULL
i=12,ncolumns=14,row[12]=F
i=13,ncolumns=14,row[13]=23284
i=0,ncolumns=4,row[0]=23284
i=1,ncolumns=4,row[1]=xxxxxxx
i=2,ncolumns=4,row[i]=NULL
i=3,ncolumns=4,row[3]=F
[Regen] ./data/23284/1.2.392.200036.9125.3.1767268739.64567296987.17567_1001_001001_12248872290003.v2 -SUCCESS

2.) Next dgate is started and the patient is deleted:

dgate -v
# sent ./dgate --deletepatient:23284
DGATE (1.4.14, build Fri Oct 31 15:36:19 2008) is running as threaded server
Server command sent using DGATE -- option
Deleting patient: 23284
Query On Image
Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta
Values: DICOMStudies.PatientID = '23284' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
Tables: DICOMImages, DICOMSeries, DICOMStudies
i=0,ncolumns=4,row[0]=1.2.392.200036.9125.4.0.135239000.39391488.440608599
i=1,ncolumns=4,row[1]=1.2.392.200036.9125.3.1767268739.64567297361.17569
i=2,ncolumns=4,row[2]=23284
i=3,ncolumns=4,row[3]=1.2.392.200036.9125.2.1767268739.64567296987.17566
i=0,ncolumns=4,row[0]=1.2.392.200036.9125.4.0.135238488.31920384.440608599
i=1,ncolumns=4,row[1]=1.2.392.200036.9125.3.1767268739.64567296987.17567
i=2,ncolumns=4,row[2]=23284
i=3,ncolumns=4,row[3]=1.2.392.200036.9125.2.1767268739.64567296987.17566
Records = 2
RemoveFromPACS 2 images
i=0,ncolumns=2,row[0]=23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2
i=1,ncolumns=2,row[1]=MAG0
Removed file: [MAG0:23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2]
IOD File being removed: ./data/23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2
i=0,ncolumns=1,row[0]=1.2.392.200036.9125.4.0.135239000.39391488.440608599
i=0,ncolumns=1,row[0]=1.2.392.200036.9125.2.1767268739.64567296987.17566
i=0,ncolumns=1,row[0]=23284
i=0,ncolumns=2,row[0]=23284/1.2.392.200036.9125.3.1767268739.64567296987.17567_1001_001001_12248872290003.v2
i=1,ncolumns=2,row[1]=MAG0
Removed file: [MAG0:23284/1.2.392.200036.9125.3.1767268739.64567296987.17567_1001_001001_12248872290003.v2]
IOD File being removed: ./data/23284/1.2.392.200036.9125.3.1767268739.64567296987.17567_1001_001001_12248872290003.v2
i=0,ncolumns=1,row[0]=1.2.392.200036.9125.4.0.135238488.31920384.440608599

3.) Finally the print out after sending the regendir command:
# ./dgate --regendir:MAG0,23284

Server command sent using DGATE -- option
[Regen] ./data/23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2 -SUCCESS
i=0,ncolumns=14,row[0]=1.2.392.200036.9125.2.1767268739.64567296987.17566
Segmentation fault

####
Perhaps something is left in the database that should have been removed with the "deletepatient" command ?

I'm happy to do anything I can to help!

Tego

Tego · Oct 31st 2008

Marcel,

I should have mentioned that I explicitly tested for a NULL string and printed the word "NULL" when row[i] IS a null pointer. Else I printed the actual string.
Tego

marcelvanherk · Nov 1st 2008

Hi,

I think we have no established that ncolumns is correct. This means that Vptrs[i] is incorrect. These are set by BindField. Can you log bindfield activity as well?

Marcel

Tego · Nov 1st 2008

Marcel,
Following is a printout using %p for row[i] and vPtrs[i]. I also have another clue (I think). IF I run --deletepatient twice
on the same patient ID and then run --regendir the system does NOT crash. This patient has two images which might be another clue.

**Initial startup with ./dgate -v -r with the single patient in MAG0
----------------------------------------------------------------------------------------------
Step 2: Load / Add DICOM Object files
Regen Device 'MAG0'
[Regen] ./data/23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2 -SUCCESS
row[0]=0x9905f4c,vPtr[0]=0x80481f8
row[1]=0x9905f7f,vPtr[1]=0xbfd036a4
row[2]=0x9905f88,vPtr[2]=0xbfd037a4
row[3]=(nil),vPtr[3]=0xbfd038a4
row[4]=(nil),vPtr[4]=0xbfd039a4
row[5]=(nil),vPtr[5]=0xbfd03aa4
row[6]=(nil),vPtr[6]=0xbfd03ba4
row[7]=(nil),vPtr[7]=0xbfd03ca4
row[8]=(nil),vPtr[8]=0xbfd03da4
row[9]=0x9905f93,vPtr[9]=0xbfd03ea4
row[10]=0x9905f96,vPtr[10]=0xbfd03fa4
row[11]=(nil),vPtr[11]=0xbfd040a4
row[12]=0x9905fa6,vPtr[12]=0xbfd041a4
row[13]=0x9905fa8,vPtr[13]=0xbfd042a4
row[0]=0x9905f24,vPtr[0]=0x80481f8
row[1]=0x9905f2a,vPtr[1]=0xbfd036a4
row[2]=(nil),vPtr[2]=0xbfd037a4
row[3]=0x9905f3a,vPtr[3]=0xbfd038a4
[Regen] ./data/23284/1.2.392.200036.9125.3.1767268739.64567296987.17567_1001_001001_12248872290003.v2 -SUCCESS
Regeneration Complete
[root@pacs1 conquest]#

#run --deletepatient
-------------------------------------------------------------
[root@pacs1 conquest]# ./dgate -v
DGATE (1.4.14, build Sat Nov 1 12:19:15 2008) is running as threaded server
Server command sent using DGATE -- option
Deleting patient: 23284
Query On Image
Issue Query on Columns: DICOMImages.SOPInstanc, DICOMSeries.SeriesInst, DICOMStudies.PatientID, DICOMStudies.StudyInsta
Values: DICOMStudies.PatientID = '23284' and DICOMSeries.StudyInsta = DICOMStudies.StudyInsta and DICOMImages.SeriesInst = DICOMSeries.SeriesInst
Tables: DICOMImages, DICOMSeries, DICOMStudies
row[0]=0x8580c6c,vPtr[0]=0x857a398
row[1]=0x8580ca1,vPtr[1]=0x857a4d0
row[2]=0x8580cd4,vPtr[2]=0x857a608
row[3]=0x8580cda,vPtr[3]=0x8584c08
row[0]=0x8580d34,vPtr[0]=0x857a398
row[1]=0x8580d69,vPtr[1]=0x857a4d0
row[2]=0x8580d9c,vPtr[2]=0x857a608
row[3]=0x8580da2,vPtr[3]=0x8584c08
Records = 2
RemoveFromPACS 2 images
row[0]=0x858084c,vPtr[0]=0xb7ed412a
row[1]=0x85808a3,vPtr[1]=0xb7ed402a
Removed file: [MAG0:23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2]
IOD File being removed: ./data/23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2
row[0]=0x8580848,vPtr[0]=0xb7ed3d18
row[0]=0x8580848,vPtr[0]=0xb7ed3d18
row[0]=0x8580848,vPtr[0]=0xb7ed3d18
row[0]=0x858084c,vPtr[0]=0xb7ed412a
row[1]=0x85808a3,vPtr[1]=0xb7ed402a
Removed file: [MAG0:23284/1.2.392.200036.9125.3.1767268739.64567296987.17567_1001_001001_12248872290003.v2]
IOD File being removed: ./data/23284/1.2.392.200036.9125.3.1767268739.64567296987.17567_1001_001001_12248872290003.v2
row[0]=0x8580848,vPtr[0]=0xb7ed3d18

# Run --regendir:MAG0,23284
------------------------------------------------------------------
Server command sent using DGATE -- option
[Regen] ./data/23284/1.2.392.200036.9125.3.1767268739.64567297361.17569_1002_001002_12248872300004.v2 -SUCCESS
row[0]=0x861cb64,vPtr[0]=(nil)
Segmentation fault

Tego

Is there a command I could call to run through NextRecord AFTER doing the delete so we could see the state
of row[] and vPtrs[] ?

marcelvanherk · Nov 3rd 2008

Hi Tego,

vptrs is directly set by Database:Bindfield. So it would be nice to log those calls. It could be that vptrs is overwritten somewere.

Marcel

marcelvanherk · Nov 3rd 2008

Hi,

looking at your last post, I may have found it. You see VPTR[1]...[N] fall nicely in a sequence, but VPTR[0] is not. Looking at the code in dbsql.cpp, I see that is is actaually never filled in function UpdateOrAddToTable! So the query asks for the UID in the database, but never actually reads it. So the crash occurs when the pointer in VPTR[0] is invalid from a previous operation.

Code

for (i=1; i<=lastfield; i++)		{		if(!DB.BindField (i+1, SQL_C_CHAR, s[i-1], 255, &sdword))			return ( FALSE );		s[i-1][0] = 0;		}

Try to add here after:

Code

char dum[256];
DB.BindField (1, SQL_C_CHAR, dum, 255, &sdword));

I am curious wether this helps for this and maybe a few other mystery crashes!
Marcel

Tego · Nov 4th 2008

Hi Marcel,

Good catch !

I added a global var at the top of the file just before the "forward declarations" in dbsql.cpp.

Code

//TKchar dummy[256]={0};

Then I added your snippet following the initialiation loop
Existing code:

Quote

for (i=1; i<=lastfield; i++)
{
if(!DB.BindField (i+1, SQL_C_CHAR, s[i-1], 255, &sdword))
return ( FALSE );
s[i-1][0] = 0;
}

Display More

New code:

Code

//TK
// Added global var dummy[256] at top of file.
 DB.BindField (1, SQL_C_CHAR, dummy, 255, &sdword);

This fixed my test case for --deletepatient, --regendir. I'm going to comment out the code and see if I can
get dgate to crash with the "--deleteseries" noted by markpearson.
If I can duplicate his crash then I'll reenable this code and see if it fixes that problem also.

Thanks!
Tego

Segmentation fault after regendir

Participate now!

Share