Bugs item #1905467, was opened at 2008-03-01 16:17
Message generated for change (Comment added) made by mobigital
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1905467&group_id=56967
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Core
Group: MonetDB Common CVS Head
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: mobigital (mobigital)
Assigned to: Nobody/Anonymous (nobody)
Summary: access violation in GDKreallocmax
Initial Comment:
Compiled with DEBUG on windows 2003 64 bit Enterprise edition.
I was importing records with COPY TO a staging table in batches of 250K rows.
Then copying them into final table.
After completing 4,750,000 rows and importing a new batch the below exception
occurs in GDKreallocmax at the last line of the snippet below:
Can someone point me in the right direction on how to debug this?
[from gdk_utils.mx]
ptr
GDKreallocmax(void *blk, size_t size, size_t * maxsize, int emergency)
{
ssize_t oldsize = 0, *s = (ssize_t *) blk;
if (s == NULL) {
return GDKmallocmax(size, maxsize, emergency);
}
#ifdef GDK_MEM_NULLALLOWED
if (size == 0) {
GDKfree(blk);
*maxsize = 0;
return NULL;
}
#endif
if (size <= 0) {
GDKfatal("GDKreallocmax: called with size %u", size);
}
size = (size + 7) & ~7; /* round up to a multiple of eight */
>>> exception occurs below >>>>>>
oldsize = GDK_MEM_BLKSIZE(s);
("s"=0x00000000100e0000)
Unhandled exception at 0x00c4c7b2 (libbat.dll) in mserver5.exe: 0xC0000005:
Access violation reading location 0x00000000100dfff8.
libbat.dll!GDKreallocmax(void * blk=0x00000000100e0000, unsigned __int64
size=211952, unsigned __int64 * maxsize=0x000000000bc41c28, int emergency=0)
Line 1164 + 0x5 bytes C
libbat.dll!HEAPextend(Heap * h=0x000000000bc41c28, unsigned __int64
size=211947) Line 205 + 0x24 bytes C
libbat.dll!strPut(Heap * h=0x000000000bc41c28, unsigned int *
dst=0x0000000106666ffc, char * v=0x000000001d4852a8) Line 2060 + 0x12 bytes
C
libbat.dll!BATappend(BAT * b=0x000000000e106968, BAT * n=0x000000000e3183a8,
char force='') Line 353 + 0x58c bytes C
lib_sql.dll!tr_update_bat(sql_trans * tr=0x0000000008b57da8, sql_delta *
obat=0x000000000c4974d8, sql_delta * cbat=0x000000000c482a18, __int64 *
cnt=0x0000000008cb54d0) Line 909 C
lib_sql.dll!update_table(sql_trans * tr=0x0000000008b57da8, sql_table *
ft=0x0000000008cb5498, sql_table * tt=0x0000000008cb55c8) Line 1001 C
lib_sql.dll!rollforward_update_table(sql_trans * tr=0x0000000008b57da8,
sql_table * ft=0x0000000008cb5498, sql_table * tt=0x0000000008cb55c8) Line
2210 + 0x18 bytes C
lib_sql.dll!rollforward_changeset_updates(sql_trans * tr=0x0000000008b57da8,
changeset * fs=0x00000000016611e8, changeset * ts=0x00000000016610d8, sql_base
* b=0x00000000016610b8, int (sql_trans *, sql_base *, sql_base *)*
rollforward_updates=0x000000000b561cd0, sql_base * (sql_trans *, sql_base *)*
rollforward_creates=0x000000000b561770, int (sql_trans *, sql_base *)*
rollforward_deletes=0x000000000b5612b0, sql_base * (sql_trans *, int, sql_base
*, sql_base *)* fd=0x000000000b562050) Line 1919 + 0x19 bytes C
lib_sql.dll!rollforward_update_schema(sql_trans * tr=0x0000000008b57da8,
sql_schema * fs=0x00000000016611c8, sql_schema * ts=0x00000000016610b8) Line
2278 + 0x57 bytes C
lib_sql.dll!rollforward_changeset_updates(sql_trans * tr=0x0000000008b57da8,
changeset * fs=0x0000000008b57dd8, changeset * ts=0x0000000008b57d28, sql_base
* b=0x0000000008b57cf8, int (sql_trans *, sql_base *, sql_base *)*
rollforward_updates=0x000000000b5619b0, sql_base * (sql_trans *, sql_base *)*
rollforward_creates=0x000000000b561640, int (sql_trans *, sql_base *)*
rollforward_deletes=0x000000000b5610d0, sql_base * (sql_trans *, int, sql_base
*, sql_base *)* fd=0x000000000b55edc0) Line 1919 + 0x19 bytes C
lib_sql.dll!rollforward_trans(sql_trans * tr=0x0000000008b57da8) Line 2300 +
0x59 bytes C
lib_sql.dll!sql_trans_commit(sql_trans * tr=0x0000000008b57da8) Line 2658 +
0xa bytes C
lib_sql.dll!mvc_commit(mvc * m=0x0000000008e8e768, int chain=0, char *
name=0x0000000000000000) Line 414 + 0xa bytes C
lib_sql.dll!SQLautocommit(CLIENT * c=0x00000001800919e8, mvc *
m=0x0000000008e8e768) Line 694 + 0xf bytes C
lib_sql.dll!SQLreader(CLIENT * c=0x00000001800919e8) Line 751 + 0xf bytes
C
libmal.dll!runPhase(CLIENT * c=0x00000001800919e8, int phase=0) Line 590 +
0x16 bytes C
libmal.dll!runScenarioBody(CLIENT * c=0x00000001800919e8) Line 612 + 0x1d
bytes C
libmal.dll!runScenario(CLIENT * c=0x00000001800919e8) Line 653 + 0xa bytes
C
libmal.dll!MSserveClient(void * dummy=0x00000001800919e8) Line 473 C
pthreadVC2d.dll!ptw32_threadStart(void * vthreadParms=0x000000000b8ec7a0) Line
219 + 0x9 bytes C
msvcr90d.dll!_callthreadstartex() Line 348 + 0x17 bytes C
msvcr90d.dll!_threadstartex(void * ptd=0x00000000015c3fa0) Line 331 C
kernel32.dll!0000000077d6b6da()
[Frames below may be incorrect and/or missing, no symbols loaded for
kernel32.dll]
----------------------------------------------------------------------
>Comment By: mobigital (mobigital)
Date: 2008-03-02 22:18
Message:
Logged In: YES
user_id=2024528
Originator: YES
Yes this was reproduced using the HEAD of MonetDB.
should I add some type of member to Heap to store how it was allocated?
because when I get another access violation it would be after the fact.
----------------------------------------------------------------------
Comment By: Peter Boncz (boncz)
Date: 2008-03-02 16:54
Message:
Logged In: YES
user_id=591107
Originator: NO
this appears to be a memory management bug; like if memory that is
allocated in memory mapped mode (hp->storage & STORE_MMAP) would be
extended as if it were mallocced (hp->storage == STORE_MEM)
I say this because malloced memory in MonetDB is always preceded by 8
extra bytes that store the block size (GDKmalloc returns pointer+8). So the
address being perfectly 0000 aligned (and -8 being fff8) is possible,but
not likely. More likely is that the 0000 aligned address was produced by a
memory map (GDKmmap).
If the problem was reproducable, I would try to break on the HEAPextend
calls for this heap (set a conditional to h=0x000000000bc41c28 -- if it is
reproducable) and figure out what the storage modes are (mmap or malloc
before and after allocation). The relatively small size of the heap (211KB)
makes me think it should be ony malloced..
In any case, what version of MonetDB are you using (really the head?)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=482468&aid=1905467&group_id=56967
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Monetdb-bugs mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/monetdb-bugs
