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
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. –
@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. –
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