# Awaria, zawieszenie lub pusty plik PDF na Linux z podłączonym debugerem
Na Linux, podłączenie debugera do aplikacji może spowodować zawieszenie IronPDF, zwrócenie pustego pliku PDF lub cichą awarię. Dzieje się to zawsze, gdy dołączony jest debuger, niezależnie od dystrybucji Linux ani wersji .NET.
IronPDF renderuje za pomocą CEF (Chromium Embedded Framework), który domyślnie uruchamia osobne, działa w piaskownicy procesy podrzędne do obsługi renderowania. Na Linux te procesy podrzędne są zablokowane, więc nie mogą być śledzone za pomocą `ptrace`, a proces może mieć tylko jeden śledzenia jednocześnie. Dołączenie debugera koliduje ze sposobem, w jaki Chromium uruchamia swoje procesy podrzędne działające w piaskownicy, więc procesy renderowania się zawieszają. Twoja aplikacja widzi to jako zawieszenie, pusty plik PDF lub cichą awarię.
## Rozwiązanie
**Zalecane: włącz tryb jednego procesu.** Ustaw go podczas uruchamiania aplikacji, przed pierwszą operacją IronPDF:
```csharp
IronPdf.Installation.SingleProcess = true;
```
Tryb jednego procesu utrzymuje renderowanie w głównym procesie, więc nie ma dziecka sandboxa, z którym debuger mógłby kolidować.
Ponieważ to ustawienie wyłącza izolację procesów CEF i jest mniej stabilne pod obciążeniem, nie używaj go w produkcji. Ogranicz to do kompilacji debugowania, aby nigdy nie było wysyłane w wersji:
```csharp
#if DEBUG
IronPdf.Installation.SingleProcess = true;
#endif
```
[[w:(Tryb jednego procesu wyłącza izolację procesów CEF i jest mniej stabilny pod obciążeniem. Usuń go lub wyklucz z kompilacji dystrybucyjnych przed wdrożeniem.)]]
Na Linux, podłączenie debugera do aplikacji może spowodować zawieszenie IronPDF, zwrócenie pustego pliku PDF lub cichą awarię. Dzieje się to zawsze, gdy dołączony jest debuger, niezależnie od dystrybucji Linux ani wersji .NET.
IronPDF renderuje za pomocą CEF (Chromium Embedded Framework), który domyślnie uruchamia osobne, działa w piaskownicy procesy podrzędne do obsługi renderowania. Na Linux te procesy podrzędne są zablokowane, więc nie mogą być śledzone za pomocą ptrace, a proces może mieć tylko jeden śledzenia jednocześnie. Dołączenie debugera koliduje ze sposobem, w jaki Chromium uruchamia swoje procesy podrzędne działające w piaskownicy, więc procesy renderowania się zawieszają. Twoja aplikacja widzi to jako zawieszenie, pusty plik PDF lub cichą awarię.
Rozwiązanie
Zalecane: włącz tryb jednego procesu. Ustaw go podczas uruchamiania aplikacji, przed pierwszą operacją IronPDF:
IronPdf.Installation.SingleProcess = true;
IronPdf.Installation.SingleProcess = true;
IronPdf.Installation.SingleProcess = True
IronPdf.Installation.SingleProcess = True
Tryb jednego procesu utrzymuje renderowanie w głównym procesie, więc nie ma dziecka sandboxa, z którym debuger mógłby kolidować.
Ponieważ to ustawienie wyłącza izolację procesów CEF i jest mniej stabilne pod obciążeniem, nie używaj go w produkcji. Ogranicz to do kompilacji debugowania, aby nigdy nie było wysyłane w wersji:
Ostrzeżenie: Tryb jednego procesu wyłącza izolację procesów CEF i jest mniej stabilny pod obciążeniem. Usuń go lub wyklucz z kompilacji dystrybucyjnych przed wdrożeniem.
Curtis Chau posiada tytuł licencjata z informatyki (Uniwersytet Carleton) i specjalizuje się w front-endowym rozwoju, z ekspertką w Node.js, TypeScript, JavaScript i React. Pasjonuje się tworzeniem intuicyjnych i estetycznie przyjemnych interfejsów użytkownika, Curtis cieszy się pracą z nowoczesnymi frameworkami i tworzeniem dobrze zorganizowanych, atrakcyjnych wizualnie podręczników.
