Problem with memory management in Join LHS

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Run Udayan-avg-Duration.pgy
2. It will either segfault or abort while performing one of the joins' LHS

Stack Trace of a segfault:

#0  0x0000003c54a88723 in memcpy () from /lib64/libc.so.6
#1  0x000000000046c91d in CopyOverlappingContent (this=0x7ffef0004bb0, 
num=8380420) at Column/headers/StorageUnit.h:100
#2  MMappedStorage::Done (this=0x7ffef0004bb0, num=8380420) at 
Column/source/MMappedStorage.cc:212
#3  0x000000000046a854 in Column::Done (this=<value optimized out>, 
numBytes=<value optimized out>) at Column/source/Column.cc:170
#4  0x000000000046c48f in Iterator::Done (this=0x7ffff2b57930, iterateMe=...) 
at Column/source/Iterator.cc:172
#5  0x00007fffe972eca8 in Done (workDescription=<value optimized out>, 
result=...) at ../../../Headersdp/ColumnIterator.cc:63
#6  JoinLHSWorkFunc_apjoin (workDescription=<value optimized out>, result=...) 
at apjoin.cc:333
#7  0x0000000000471159 in CPUWorkerImp::DoSomeWork (_obj=<value optimized out>, 
_msg=<value optimized out>) at CPUWorkers/source/CPUWorkerImp.cc:67
#8  0x0000000000522b15 in EventProcessorImp::Spin (this=0x7fcde0) at 
Messaging/source/EventProcessorImp.cc:96
#9  0x00000000005229c9 in EventProcessorImp::ForkAndSpinThread (aux=<value 
optimized out>) at Messaging/source/EventProcessorImp.cc:141
#10 0x0000003c552077f1 in start_thread () from /lib64/libpthread.so.0
#11 0x0000003c54ae5ccd in clone () from /lib64/libc.so.6

Error message from an abort:

dp: NumaMemoryAllocator/source/NumaMemoryAllocator.cc:561: void 
NumaMemoryAllocator::Coalesce(void*): Assertion 
`(chunkInfo->sizeInfo).sizeStruct.isFree == false' failed.

Stack trace from the abort:

#0  0x0000003c54a32885 in raise () from /lib64/libc.so.6
#1  0x0000003c54a34065 in abort () from /lib64/libc.so.6
#2  0x0000003c54a2b9fe in __assert_fail_base () from /lib64/libc.so.6
#3  0x0000003c54a2bac0 in __assert_fail () from /lib64/libc.so.6
#4  0x0000000000525877 in NumaMemoryAllocator::Coalesce (this=0x7fffe4001970, 
ptr=<value optimized out>) at 
NumaMemoryAllocator/source/NumaMemoryAllocator.cc:561
#5  0x0000000000525aef in NumaMemoryAllocator::MmapFree (this=0x7fffe4001970, 
ptr=0x7ffba4c80000) at NumaMemoryAllocator/source/NumaMemoryAllocator.cc:490
#6  0x000000000049d9d7 in SerializedSegmentArray::~SerializedSegmentArray 
(this=0x7ffff2b57410, __in_chrg=<value optimized out>) at 
Hash/source/SerializedSegmentArray.cc:28
#7  0x00007fffe9734f84 in JoinLHSWorkFunc_gendernetflow (workDescription=<value 
optimized out>, result=...) at gendernetflow.cc:357
#8  0x0000000000471159 in CPUWorkerImp::DoSomeWork (_obj=<value optimized out>, 
_msg=<value optimized out>) at CPUWorkers/source/CPUWorkerImp.cc:67
#9  0x0000000000522b15 in EventProcessorImp::Spin (this=0x7fcde0) at 
Messaging/source/EventProcessorImp.cc:96
#10 0x00000000005229c9 in EventProcessorImp::ForkAndSpinThread (aux=<value 
optimized out>) at Messaging/source/EventProcessorImp.cc:141
#11 0x0000003c552077f1 in start_thread () from /lib64/libpthread.so.0
#12 0x0000003c54ae5ccd in clone () from /lib64/libc.so.6

Original issue reported on code.google.com by udayan.k...@gmail.com on 22 Jun 2012 at 9:13

[GoogleCodeExporter]

I saw this happen myself.

Original comment by Luminaire1202 on 22 Jun 2012 at 9:13

• Changed state: Accepted

[GoogleCodeExporter]

This is probably related to the problem where if you have duplicate values in 
the join attributes on the left hand side, things to terribly wrong.

There will be duplicates in line 14 (AP) because there will be two tuples for 
each access point id, one for each gender.

Original comment by Luminaire1202 on 22 Jun 2012 at 9:27