2017-10-09 75 views
6

Zdaję sobie sprawę, że jest wiele miejsc, w których mogę zadać to pytanie, ale pomyślałem, że spróbuję tutaj. Wydaje mi się, że osiągnąłem już tak dużo pomocy od dobrych ludzi z Maximy.Błąd SBCL: "Wiązanie stosu wyczerpane" podczas uruchamiania Maxima na maszynie Linux

Uruchamiam Maxima z SBCL i konsekwentnie dostaję błędy;

INFO: Binding stack guard page unprotected 
Binding stack guard page temporarily disabled: proceed with caution 

Maxima encountered a Lisp error: 

Binding stack exhausted. 

PROCEED WITH CAUTION. 

Automatically continuing. 
To enable the Lisp debugger set *debugger-hook* to nil. 
INFO: Binding stack guard page reprotected 

Mam zmodyfikowano wywołanie Maxima (jego wykonywalnego) poprzez dodanie większej wartości dla dynamicznego wielkości przestrzeni i kontroli wielkości stosu i mam spojrzał na ./.../sbcl -help dla wszelkich pomysłów argumentów do dodania do $ MAXIMA_LISP_OPTIONS w pliku wykonywalnym maxima.

Dodatkowo, zwykle zrobić to tuż przed go uruchomić (chociaż wyobrażam sobie, że są zbędne, gdy system operacyjny jest inteligentny, dobrze może ostatni musi być bawił);

sudo fstrim -v/
echo 3 | sudo tee /proc/sys/vm/drop_caches 
echo 262144 | sudo tee /proc/sys/vm/max_map_count 

i po paru obliczeń robiąc moją pracę Maxima, ja dorzucę parę

:lisp (sb-ext:gc :full t) 

w nadziei na uniknięcie tego błędu. Nie znam seplenienia tak dobrze i na pewno nie rozumiem wszystkiego, co dotyczy zbierania śmieci.

Moje obliczenia są dość intensywne i rekurencyjne, chociaż ja wykorzystując memoization w pracach Maxima. Mój komputer jest opisany przez inxi -b jak

System: Host: XXX-MacBookPro Kernel: 4.10.0-33-generic x86_64 (64 bit) Desktop: Cinnamon 3.4.6 
      Distro: Linux Mint 18.2 Sonya 
Machine: System: Apple (portable) product: MacBookPro11 3 v: 1.0 
      Mobo: Apple model: Mac-2BD1B313 v: MacBookPro11 3 
      Bios: Apple v: MBP112.88Z.0138.B25.1702171721 date: 02/17/2017 
CPU:  Quad core Intel Core i7-4980HQ (-HT-MCP-) speed/max: 1402/4000 MHz 
Graphics: Card: NVIDIA GK107M [GeForce GT 750M Mac Edition] 
      Display Server: X.Org 1.18.4 drivers: nvidia (unloaded: fbdev,vesa,nouveau) 
      Resolution: [email protected] 
      GLX Renderer: GeForce GT 750M/PCIe/SSE2 GLX Version: 4.5.0 NVIDIA 375.66 
Network: Card-1: Broadcom BCM4360 802.11ac Wireless Network Adapter driver: wl 
      Card-2: Broadcom NetXtreme BCM57762 Gigabit Ethernet PCIe driver: tg3 
Drives: HDD Total Size: 1000.6GB (17.5% used) 
Info:  Processes: 291 Uptime: 43 min Memory: 3366.6/15953.7MB Client: Shell (bash) inxi: 2.2.35 

i mój Maxima i SBCL są zbudowane z GIT i są całkiem nowy ~ około 2 tygodni, a od głowy i przeszły wszystkie testy ich wykonania. Dodatkowo wygląda mój zamiana;

[email protected] ~/ResearchWC $ cat /proc/swaps 
Filename    Type  Size Used Priority 
/70GiB.swap        file  73400316 0 -2 
/dev/sda7        partition 25564776 0 -1 

i często jestem w zasadzie z pamięci i około 20-30G na wymianę.

Zwykle wydaje się powiesić w końcu (po 100 godzin powiedzieć, jak ja zauważam htop przestaje wykazujące pewną aktywność, a wentylator nie idzie w górę iw dół) i myślę, że błędy są czasami wyczerpanie pochowany w osadzonym rekursywnego połączenia. Dostałem ten komunikat o błędzie powyżej, ponieważ unikałem wywoływania funkcji na żądanym poziomie rekurencji, a zamiast tego budowałem je "ręcznie" na terminalu. E.G., zamiast tylko wywołać coś takiego jak fib (10), zamiast tego wywołałem kolejno fib (1), fib (2), fib (3), gdzie każda poprzednia wartość została zapamiętana.

Mam czas, ale najwyraźniej nie wiem, jak zmaksymalizować mój zamiany - oglądając htop Nigdy nie widziałem, aby użyć więcej niż powiedzieć ~ 25%.

1.) Czy ktoś wie, co jeszcze mogę zrobić z SBCL aby uniknąć tych błędów?

2.) Czy inne seplenienie byłoby lepszym rozwiązaniem w takich sytuacjach, np. ecl, cml, itp.?

Z góry dziękuję za radę, a w razie potrzeby mogę podać więcej szczegółów.

UPDATE

Po upping dynamiczne wielkości obszaru, rozmiar stosu i wiązania rozmiar stosu, byłem przeciwko limitu sterty zamiast stosu wiążącego tym czasie, kiedy rozbił się. Załączony jest wynik śledzenia wstecznego (Nie jestem pewien, jakie są dwa rejestry pc i fp ... - licznik programu i wskaźnik ramki?). Pobiegłem z tego śladu (pozostałość Taylor), jak również, ale nigdy nie widziałem czegoś rybi ...

ldb> backtrace 
Backtrace: 
    0: SB-BIGNUM::MULTIPLY-BIGNUM-AND-FIXNUM, pc = 0x21cb1336, fp = 0x7ffff3943f18 
    1: SB-KERNEL::TWO-ARG-*, pc = 0x21cb00a7, fp = 0x7ffff3943f98 
    2: MAXIMA::CTIMES, pc = 0x21e076b4, fp = 0x7ffff3943fc0 
    3: MAXIMA::PCTIMES, pc = 0x21de5f4c, fp = 0x7ffff3943ff0 
    4: MAXIMA::PCTIMES1, pc = 0x21e78f1e, fp = 0x7ffff3944048 
    5: MAXIMA::PCTIMES, pc = 0x21de6033, fp = 0x7ffff3944078 
    6: MAXIMA::PCETIMES1, pc = 0x21fe0560, fp = 0x7ffff39440d8 
    7: MAXIMA::PTIMES1, pc = 0x21f457e5, fp = 0x7ffff3944148 
    8: MAXIMA::PTIMES, pc = 0x21db6561, fp = 0x7ffff3944180 
    9: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39441b8 
    10: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39441f0 
    11: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944228 
    12: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944260 
    13: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944298 
    14: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39442d0 
    15: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944308 
    16: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944340 
    17: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944378 
    18: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39443b0 
    19: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39443e8 
    20: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944420 
    21: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944458 
    22: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944490 
    23: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39444c8 
    24: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944500 
    25: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944538 
    26: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944570 
    27: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39445a8 
    28: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39445e0 
    29: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944618 
    30: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944650 
    31: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944688 
    32: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39446c0 
    33: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39446f8 
    34: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944730 
    35: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944768 
    36: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39447a0 
    37: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39447d8 
    38: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944810 
    39: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944848 
    40: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944880 
    41: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39448b8 
    42: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39448f0 
    43: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944928 
    44: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944960 
    45: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944998 
    46: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39449d0 
    47: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944a08 
    48: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944a40 
    49: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944a78 
    50: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944ab0 
    51: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944ae8 
    52: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944b20 
    53: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944b58 
    54: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944b90 
    55: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944bc8 
    56: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944c00 
    57: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944c38 
    58: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944c70 
    59: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944ca8 
    60: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944ce0 
    61: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944d18 
    62: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944d50 
    63: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944d88 
    64: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944dc0 
    65: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944df8 
    66: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944e30 
    67: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944e68 
    68: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944ea0 
    69: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944ed8 
    70: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944f10 
    71: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944f48 
    72: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944f80 
    73: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3944fb8 
    74: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3944ff0 
    75: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945028 
    76: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945060 
    77: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945098 
    78: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39450d0 
    79: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945108 
    80: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945140 
    81: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945178 
    82: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39451b0 
    83: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39451e8 
    84: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945220 
    85: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945258 
    86: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945290 
    87: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39452c8 
    88: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945300 
    89: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945338 
    90: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945370 
    91: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39453a8 
    92: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39453e0 
    93: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945418 
    94: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945450 
    95: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff3945488 
    96: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff39454c0 
    97: MAXIMA::PSIMP, pc = 0x21dd0617, fp = 0x7ffff39454f8 
    98: MAXIMA::PALGSIMP, pc = 0x22166db7, fp = 0x7ffff3945530 
+1

Stos i sterty to dwie różne rzeczy. "Wyczerpany stos bindowania" zwykle wskazuje na dużą głębokość rekursji. Duża sterty/zamiana byłaby spowodowana przez wyciek pamięci lub GC, który nie może zwolnić całej pamięci. Najlepszym miejscem do zadawania pytań jest lista dyskusyjna SBCL. Alternatywną implementacją będzie Clozure CL. –

+0

@RainerJoswig Czy istnieje sposób określenia maksymalnej wysokości stosu wywołań w Common Lisp? a jeśli nie, to specjalnie dla SBCL? Przypominam sobie, że istnieje stała, która mówi o maksymalnej głębokości stosu, ale wyszukiwanie w Internecie nie wydaje się znaleźć coś takiego. Być może jest to trochę myślenia pobożnego z mojej strony. –

+0

Jedyne miejsce, w którym widzę wzmiankę o "maksymalnej głębokości stosu wywołań", jest używane w profilowaniu, sekcja 15.2.4 i 15.2.5 na stronie http://sbcl.org/manual/index.html oraz opis wiązania i odrywania w podręcznik obsługi wewnętrznej w sekcji 8.2 na stronie http://sbcl.org/sbcl-internals/Binding-and-unbinding.html#Binding-and-unbinding. Szybkie dwa pytanie (może to, co @RobertDodier zapytał @RainerJoswig) to głębokość stosu wiążącego kontrolowana przez jakąś modyfikowalną zmienną i czy "kontrolowanie wielkości stosu" ma na to jakiś wpływ? Widziałem #define w validate.h ustawienie BINDING_STACK_SIZE na 1024 * 1024 ... Czy mogę zwiększyć? – nate

Odpowiedz

4

Najczęstszą przyczyną wiążą przepełnienie stosu jest rekurencyjna funkcja, która zwraca się w nieskończoność (czyli błąd w rekursji). Drugą najczęstszą przyczyną jest funkcja rekurencyjna, która jest poprawnie zaprogramowana, ale wywołuje się zbyt wiele razy, aby implementacja Lisp mogła sobie z nią poradzić.

Nie pamiętam, jaki jest limit stosu dla SBCL - może to być 8192, ale to tylko domysły. Prawdopodobnie można to ustalić eksperymentalnie (jeśli nie czytając dokumentacji SBCL).

W obu przypadkach można spróbować dowiedzieć się, która funkcja lub funkcje są przyczyną kłopotów poprzez

trace (mymaximafun1, mymaximafun2, ...); 

dla funkcji Maxima i/lub

:lisp (trace mylispfun1 mylispfun2 ...) 

dla funkcji Lisp.

Drugim problemem jest próba uniknięcia głębokich rekursji poprzez ponowne przetwarzanie funkcji rekursywnych w postaci iteracji.

Wspomniałeś, że masz długie obliczenia. Strategia, aby zmniejszyć efekt awarii jest wywołanie funkcji save zapisywania stanu programu co jakiś czas, np:

save ("mycheckpointfile.lisp", all); 

Zauważ, że save ma dużo opcji, więc może warto zapoznać się z dokumentacją przez ? save.

Możesz automatycznie generować nazwy plików za pomocą jakiejś receptury, takiej jak file_name : printf(false, "mycheckpointfile~d.lisp", 1000 + random(9000)), która generuje losową 4-cyfrową liczbę i wkleja ją do nazwy pliku. Oczywiście istnieje wiele takich przepisów.

+0

Dzięki, Twoja sugestia śledzenia nie doprowadziła do żadnych oczywistych błędów, ale wciąż poluje ... – nate

+1

Możesz być w stanie uzyskać ślad stosu - jeśli program przejdzie do wiersza debuggera SBCL, spróbuj ': wstecznego śledzenia'. Nie wiem, czy to zadziała. –