2016-05-03 4 views
1

Ich bin in einer verkabelten Situation gefangen; mein c++ Code verbraucht mehr Speicher (um 70G erreichen), bis der gesamte Prozess getötet wurde.Speicherbelegungserhöhung

Ich rufe einen C++ Code von Python an, der den Longest common subsequence length Algorithmus implementiert.

Der C++ Code ist unten dargestellt:

#define MAX(a,b) (((a)>(b))?(a):(b)) 

#include <stdio.h> 

int LCSLength(long unsigned X[], long unsigned Y[], int m, int n) 
{ 

    int** L = new int*[m+1]; 
    for(int i = 0; i < m+1; ++i) 
    L[i] = new int[n+1]; 

    printf("i am hre\n"); 

    int i, j; 
    for(i=0; i<=m; i++) 
    { 
    printf("i am hre1\n"); 
    for(j=0; j<=n; j++) 
    { 
     if(i==0 || j==0) 
      L[i][j] = 0; 
     else if(X[i-1]==Y[j-1]) 
      L[i][j] = L[i-1][j-1]+1; 
     else 
      L[i][j] = MAX(L[i-1][j],L[i][j-1]); 
    } 
    } 
    int tt = L[m][n]; 

    printf("i am hre2\n"); 

    for (i = 0; i < m+1; i++) 
    delete [] L[i]; 

    delete [] L; 

    return tt; 
} 

Und mein Python Code ist wie folgt:

from ctypes import cdll 
import ctypes 
lib = cdll.LoadLibrary('./liblcs.so') 

la = 36840 
lb = 833841 
a = (ctypes.c_ulong * la)() 
b = (ctypes.c_ulong * lb)() 

for i in range(la): 
    a[i] = 1 
for i in range(lb): 
    b[i] = 1 

print "test" 
lib._Z9LCSLengthPmS_ii(a, b, la, lb) 

IMHO im C++ Code, nach dem new Operation, die eine große Menge zuteilen könnte von Speicher auf dem Heap, würde es nicht mehr zusätzlichen Speicherverbrauch innerhalb der loop geben.

Zu meiner Überraschung beobachtete ich jedoch, dass der verwendete Speicher während der loop weiter ansteigt. (Ich verwende top auf Linux, und es hält i am her1 drucken, bevor der Prozess getötet wurde)

Es ist verwirrt mich wirklich an diesem Punkt, als ich nach der Speicherzuordnung erraten, gibt es nur einige arithmetische Operationen innerhalb des loop, Warum benötigt der Code mehr Speicher?

Bin ich klar genug? Könnte mir jemand Hilfe zu diesem Thema geben? Vielen Dank!

+0

C und C++ sind verschiedene Sprachen sehen würde! – Olaf

+6

'4 * (36840 + 1) * (833841 + 1) * 4 = 122878292488' Es ist natürlich, mehr als 70G Speicher zu verbrauchen, wenn' int' 4 Bytes benötigt. Es wird ungefähr 114GiB verbrauchen. – MikeCAT

+1

Ich habe gehört, dass 'malloc()' nur Speicher reservieren und den Puffer tatsächlich Speicher verbrauchen wird. Dasselbe kann mit "neu" passieren. – MikeCAT

Antwort

1

Werfen Sie einen Blick auf das, was Sie tun:

#include <iostream> 

int main(){ 

    int m = 36840; 
    int n = 833841; 
    unsigned long total = 0; 

    total += (sizeof(int) * (m+1)); 

    for(int i = 0; i < m+1; ++i){ 
    total += (sizeof(int) * (n+1)); 
    } 

    std::cout << total << '\n'; 

} 

Sie sind einfach zu viel Speicher verbrauchen.
Wenn die Größe Ihres int 4 Bytes ist, ordnen Sie 122 GB zu.

2

Ihr verbraucht zu viel Speicher. Der Grund, warum das System nicht über die Zuteilung nicht sterben, weil Linux ermöglicht es Ihnen, mehr Speicher zuzuweisen, als Sie

http://serverfault.com/questions/141988/avoid-linux-out-of-memory-application-teardown 

verwenden kann ich die gleiche Sache auf einer Testmaschine gerade tat. Ich war in der Lage, über den Gebrauch von neuen hinauszukommen und die Schleife zu starten, nur wenn das System entschied, dass ich zu viel vom verfügbaren RAM aß, ​​tötete es mich.

Das habe ich bekommen. Eine schöne OOM Nachricht in dmesg.

[287602.898843] Out of memory: Kill process 7476 (a.out) score 792 or sacrifice child 
[287602.899900] Killed process 7476 (a.out) total-vm:2885212kB, anon-rss:907032kB, file-rss:0kB, shmem-rss:0kB 

Auf Linux Sie so etwas wie dies in den Kernel-Logs oder die Ausgabe von dmesg ...

[287585.306678] Out of memory: Kill process 7469 (a.out) score 787 or sacrifice child 
[287585.307759] Killed process 7469 (a.out) total-vm:2885208kB, anon-rss:906912kB, file-rss:4kB, shmem-rss:0kB 
[287602.754624] a.out invoked oom-killer: gfp_mask=0x24201ca, order=0, oom_score_adj=0 
[287602.755843] a.out cpuset=/ mems_allowed=0 
[287602.756482] CPU: 0 PID: 7476 Comm: a.out Not tainted 4.5.0-x86_64-linode65 #2 
[287602.757592] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014 
[287602.759461] 0000000000000000 ffff88003d845780 ffffffff815abd27 0000000000000000 
[287602.760689] 0000000000000282 ffff88003a377c58 ffffffff811d0e82 ffff8800397f8270 
[287602.761915] 0000000000f7d192 000105902804d798 ffffffff81046a71 ffff88003d845780 
[287602.763192] Call Trace: 
[287602.763532] [<ffffffff815abd27>] ? dump_stack+0x63/0x84 
[287602.774614] [<ffffffff811d0e82>] ? dump_header+0x59/0x1ed 
[287602.775454] [<ffffffff81046a71>] ? kvm_clock_read+0x1b/0x1d 
[287602.776322] [<ffffffff8112b046>] ? ktime_get+0x49/0x91 
[287602.777127] [<ffffffff81156c83>] ? delayacct_end+0x3b/0x60 
[287602.777970] [<ffffffff81187c11>] ? oom_kill_process+0xc0/0x367 
[287602.778866] [<ffffffff811882c5>] ? out_of_memory+0x3bf/0x406 
[287602.779755] [<ffffffff8118c646>] ? __alloc_pages_nodemask+0x8fc/0xa6b 
[287602.780756] [<ffffffff811c095d>] ? alloc_pages_current+0xbc/0xe0 
[287602.781686] [<ffffffff81186c1d>] ? filemap_fault+0x2d3/0x48b 
[287602.782561] [<ffffffff8128adea>] ? ext4_filemap_fault+0x37/0x51 
[287602.783511] [<ffffffff811a9d56>] ? __do_fault+0x68/0xb1 
[287602.784310] [<ffffffff811adcaa>] ? handle_mm_fault+0x6a4/0xd1b 
[287602.785216] [<ffffffff810496cd>] ? __do_page_fault+0x33d/0x398 
[287602.786124] [<ffffffff819c6ab8>] ? async_page_fault+0x28/0x30