Dotaz: program padá na SIGSEGV, jak odladit?

[Franta Hanzlík]

Sestavil jsem program (ne svůj), ten ale po spuštěni (zřejmě ještě ve fázi nějaké inicializace) padá na SEGV. Po doinstalaci příslušných debuginfo balíčků vypadá backtrace takto:

#0  _dl_lookup_symbol_x (undef_name=0x30bde3 "using_xterm", undef_map=0x862e0a0, ref=0xbffef550, symbol_scope=0x862e258, version=0x0, type_class=1, 
    flags=1, skip_map=0x0) at dl-lookup.c:713
#1  0x00110c98 in _dl_fixup (l=<value optimized out>, reloc_arg=<value optimized out>) at dl-runtime.c:118
#2  0x001174f0 in _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:37
#3  0x0030e1eb in terminal_initialize () at terminal.c:404
#4  0x080e5297 in iodev_init () at dev_list.c:107
#5  0x0805e335 in main (argc=1, argv=0xbffff764) at emu.c:426

Nevíte někdo co s tím? Těm bodům #3 - #0 nerozumím, předpokládám, že jsou to nějaké rutiny glibc, ale netuším o co tam přesně jde a po čem bych měl jít. Příp. zná někdo odkazy na nějakou slušnou nalejvárnu z téhle oblasti?
Díky předem.

Odpovědi

[rastos]

Máš k tomu zdrojáky, nie? Tak čo je na riadku 404 v súbore terminal.c ?

[Franta Hanzlík]

No, nic co by vypadalo závadně:

    403 
    404    if (using_xterm())
    405      Video_term.change_config = term_change_config;

Ta funkce "using_xterm()" je definována ve stejném zdrojáku o kousek výše takhle:

    305 
    306 int using_xterm(void)
    307 {
    308    char *term = getenv("TERM");
    309 
    310    if (term == NULL)
    311       return 0;
    312    
    313    return !strncmp("xterm", term, 5) ||
    314            !strncmp("rxvt", term, 4) ||
    315            !strcmp("dtterm", term);
    316 }
    317 

Na tom nic špatného taky nevidím, a ten backtrace do toho IMO neukazuje. V položené otázce mám chybu, nerozumím bodům #2 - #0, ten #3 je ještě jasný. Ale zbytek?

Ještě pro upřesnění - na Fedoře 12-13/i386 mi stejný program ze stejných zdrojáků sestavený se stejnými volbami chodí dobře, na několika počítačích.

[Franta Hanzlík]

Ještě poznatek, jestli to může být užitečné:
1) Našel jsem počítač s Fedorou 14, kde program také běhá.
2) na počítačích, kde krachuje, je jedno, zda jej spustím v consoli (TERM=linux) nebo v gnome-terminal (TERM=xterm), krachuje to stejně. Radši bych, než nějaké porovnávání konfigurace PC kde to chodí a kde ne, viděl nějaký obecný postup, jak se takovéhle problémy řeší, a co znamenají ta poslední tři volání na stacku. Máte někdo nějaký nápad?

[rastos]

Niečo je zle. To using_xterm nie je v backtrace. To znamená, že buď je to tam nejak #ifdef-nuté a to using_xterm sa skutočnosti hľadá inde a nenájde sa, alebo je došahaný stack.

a) Čo povie

nm terminal.o |grep using_xterm

?

b) môžeš to pustiť pod valgrind-om?

[Michal Kubeček]

Podle toho backtrace bych tipoval, že se funkce using_xterm() linkuje z dynamické knihovny a právě při tom nastává problém, ne až při jejím spuštění.

[Franta Hanzlík]

Jojo, některé věci si natahuje dynamicky. Příslušný kousek Makefile je zhruba:

USE_DL_PLUGINS=1        # Hlavni Makefile.conf

CFILES=term_core.c terminal.c keyb_slang.c mouse_xterm.c
OBJS=$(CFILES:.c=.o)
ifdef USE_DL_PLUGINS
$(BINPATH)/bin/libplugin_term.so: $(OBJS) $(MAPS)
        $(CC) $(LDFLAGS) -shared -o $@ $(OBJS) $(SLANGLIB)
        $(AR) crs $(LIB)
endif

a binární části jsou zhruba:

/usr/bin/xdosemu.bin
/usr/lib/dosemu
/usr/lib/dosemu/libplugin_X.so
/usr/lib/dosemu/libplugin_alsa.so
/usr/lib/dosemu/libplugin_gpm.so
/usr/lib/dosemu/libplugin_sdl.so
/usr/lib/dosemu/libplugin_sndfile.so
/usr/lib/dosemu/libplugin_term.so

Ale co s tím? Jak postupovat dál?

[Franta Hanzlík]

Tak dynamické knihovny s tím asi nesouvisí. Program se dá přeložit i bez nich, což jsem udělal - a výsledek je stejný, program padá i tak, úplně stejně.

Teď jsem do programu přidal pár ladicích výpisů do oblasti, kde docházalo k pádu - a program padá také, ale v trochu jiném místě.

Podle zdrojáků program chvíli předtím než padne několikrát volá mprotect() na různé oblasti svého kódu, nastavuje je readonly atd, takže je klidně možné, že k SEGV dojde nejen při sahnutí mimo oblast programu, ale i uvnitř.

Současný pád a backtrace vypadá takto:

Program received signal SIGSEGV, Segmentation fault.
_dl_lookup_symbol_x (undef_name=0x804abb3 "setreuid", undef_map=0x123900, ref=0xbffef4d0, symbol_scope=0x123ab8, version=0xb7fe5438, type_class=1, flags=1, 
    skip_map=0x0) at dl-lookup.c:713
713	{
(gdb) bt
#0  _dl_lookup_symbol_x (undef_name=0x804abb3 "setreuid", undef_map=0x123900, ref=0xbffef4d0, symbol_scope=0x123ab8, version=0xb7fe5438, type_class=1, 
    flags=1, skip_map=0x0) at dl-lookup.c:713
#1  0x00110c98 in _dl_fixup (l=<value optimized out>, reloc_arg=<value optimized out>) at dl-runtime.c:118
#2  0x001174f0 in _dl_runtime_resolve () at ../sysdeps/i386/dl-trampoline.S:37
#3  0x080886f7 in priv_drop () at priv.c:187
#4  0x0804e616 in main (argc=4, argv=0xbffff5f4) at emu.c:404

Není mi jasné, co se tam může dít. "priv.c" na řádku 187 volá "setreuid" s parametry (500,500), to by mělo být OK a moc by se na tom dát zkazit nemělo.

Jak by se mělo postupovat dál?

[Voty]

Pořád to souvisí s dynamickými knihovnami (viz _dl_xxx volání). V tomto případě se program pravděpodobně snaží najít tu funkci "setreuid". Ještě můžeš vyzkoušet

LD_BIND_NOW=y ./nazev_binarky

To by mělo způsobit, že se všechny symboly pokusí dynamic linker vyřešit všechny závislosti ještě před začátkem programu. Né, že by to potom začalo fungovat, ale bude jasné, že za to "může" dynamic linker.

[Franta Hanzlík]

Tak to je trefa, tohle pomohlo na všech mašinách kde to nefachalo. Jinak, já vím že dyn. knihovny v programu jsou, viz můj výpis ldd programu někde tady, ale nějak naivně jsem si myslel, že ld.so je "neprůstřelný", že takovouhle chybu prostě udělat nemůže. Ale ve Fedoře občas krev teče, ve čtrnáctce je glibc s podezřelým číslem verze 2.12.90, tj do full-2.13 asi ještě něco chybí a její dynamic linker možná není úplně košer. Zajímal by mě názor někoho, kdo do toho trochu líp vidí.

Tenhle program má shell wrapper, takže nebude problém tam definici "LD_BIND_NOW" přidat (někde jsem našel, že ani nemusí mít hodnotu "y", stačí aby byla definovaná.

Asi by to taky mělo vyřešit linkování s volbou ld "-Wl,-z now", možná to zkusím radši tak.

Díky moc!

[Voty]

Jasně, "LD_BIND_NOW" by mělo stačit, aby měla libovolnou hodnotu, to je pravda jak teď koukám :)

V jednotlivých verzích glibc se moc neorientu, takže tady nepomůžu. Avšak napadá mne, zda by nebylo možné, že program si omylem přepisuje někde v paměti co nemá a tím, že DL udělá vše již na začátku, tak to pak "jakoby nevadí", s tím, že něco může vykouknout trochu později. Tedy, že by stálo za to zjistit, co je původní příčinou.

[Franta Hanzlík]

To asi možné je, tak jestli tedy mohu otravovat ještě jednou - jde v gdb nebo jiném ladicím toolu nastavit "breakpoint" typu "trace trap, if program sáhne na definované místo/oblast v paměti"?

Nebo je nějaká jiná metoda, jak zjistit, že si program něco v sobě přepisuje? Odhaduji, že u txt sekce by to jít mohlo(mělo), ale u ostatních?

[Voty]

Mno :) Já bych to zkusil spustit znovu pod valgrind-em, ale hledal bych jen chyby, memory leaky nás (snad) nezajímají, takže kdyby to dokázalo najít nějaké chybné přístupy do paměti ...

Ačkoliv je stále možné, že chyba je skutečně v dotyčném DL (prohledal bych google na reporty).

[rastos]

(gdb) help awatch
Set a watchpoint for an expression.
A watchpoint stops execution of your program whenever the value of
an expression is either read or written.

Valgrind je vynikajúci nástroj. Vyskúšaj.

[Franta Hanzlík]

$ nm terminal.o |grep using_xterm 00000e90 T using_xterm

Překládané to asi je, žádný #ifdef se toho asi netýká.

"valgrind --leak-check=yes --log-file=v /usr/bin/dosemu.bin":

Na PC kde program fungoval funguje i teď, valgrind vytvoří asi 13kB log, na konci jsou sice nějaká hlášení o leacích, ale asi ne příliš podstatná:

==6935== HEAP SUMMARY:
==6935==     in use at exit: 38,675 bytes in 49 blocks
==6935==   total heap usage: 1,818 allocs, 1,769 frees, 194,819 bytes allocated
==6935== 
==6935== LEAK SUMMARY:
==6935==    definitely lost: 0 bytes in 0 blocks
==6935==    indirectly lost: 0 bytes in 0 blocks
==6935==      possibly lost: 0 bytes in 0 blocks
==6935==    still reachable: 38,675 bytes in 49 blocks
==6935==         suppressed: 0 bytes in 0 blocks
==6935== Reachable blocks (those to which a pointer was found) are not shown.
==6935== To see them, rerun with: --leak-check=full --show-reachable=yes
==6935== 
==6935== For counts of detected and suppressed errors, rerun with: -v
==6935== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 8)
==6935== 
==6935== HEAP SUMMARY:
==6935==     in use at exit: 423,807 bytes in 508 blocks
==6935==   total heap usage: 4,166 allocs, 3,658 frees, 11,417,093 bytes allocated
==6935== 
==6935== 12 bytes in 1 blocks are definitely lost in loss record 34 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0xDF9353: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==6935==    by 0x4475CAC: XCreateGlyphCursor (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4011A89: X_init (X.c:2426)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935==    by 0x805E334: main (in /usr/bin/dosemu.bin)
==6935== 
==6935== 124 bytes in 1 blocks are definitely lost in loss record 90 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0xB98D83: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98E3A: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB986F9: xcb_connect_to_display_with_auth_info (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98A2C: xcb_connect (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0x44A0302: _XConnectXCB (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4487F62: XOpenDisplay (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4011203: X_init (X.c:510)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935==    by 0x805E334: main (in /usr/bin/dosemu.bin)
==6935== 
==6935== 124 bytes in 1 blocks are definitely lost in loss record 91 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0xB98D83: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98E3A: ??? (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB986F9: xcb_connect_to_display_with_auth_info (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0xB98A2C: xcb_connect (in /usr/lib/libxcb.so.1.1.0)
==6935==    by 0x44A0302: _XConnectXCB (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4487F62: XOpenDisplay (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4015895: X11_DetectLayout (X_keymaps.c:73)
==6935==    by 0x813127E: setup_default_keytable (in /usr/bin/dosemu.bin)
==6935==    by 0x812F63B: keyb_server_init (in /usr/bin/dosemu.bin)
==6935==    by 0x81326BA: keyb_init (in /usr/bin/dosemu.bin)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935== 
==6935== 2,000 (80 direct, 1,920 indirect) bytes in 1 blocks are definitely lost in loss record 120 of 131
==6935==    at 0x400677E: malloc (vg_replace_malloc.c:195)
==6935==    by 0x4479193: ??? (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4479C97: XQueryFont (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0xDF92D8: XcursorTryShapeCursor (in /usr/lib/libXcursor.so.1.0.2)
==6935==    by 0x4475CAC: XCreateGlyphCursor (in /usr/lib/libX11.so.6.3.0)
==6935==    by 0x4011A89: X_init (X.c:2426)
==6935==    by 0x80E5296: iodev_init (in /usr/bin/dosemu.bin)
==6935==    by 0x805E334: main (in /usr/bin/dosemu.bin)
==6935== 
==6935== LEAK SUMMARY:
==6935==    definitely lost: 340 bytes in 4 blocks
==6935==    indirectly lost: 1,920 bytes in 2 blocks
==6935==      possibly lost: 0 bytes in 0 blocks
==6935==    still reachable: 421,547 bytes in 502 blocks
==6935==         suppressed: 0 bytes in 0 blocks
==6935== Reachable blocks (those to which a pointer was found) are not shown.
==6935== To see them, rerun with: --leak-check=full --show-reachable=yes
==6935== 
==6935== For counts of detected and suppressed errors, rerun with: -v
==6935== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 29 from 10)

Na PC kde hází SEGV se to chová jinak: do logu se zapíše cca 10kB, zdá se shodných jako na OK PC. A pak zřejmě někde cyklí, valgrind (na top-u se zobrazuje memcheck-x86-li(nux)) neustále spotřebovává 95-100% CPU a nic se neděje. Když po několika desítkách minut zkusím breaknout s CTRL/C, skončí to zase na SEGV a valgrin do logu dopíše asi 1600 Byte, tu část od "Process terminating with default action of signal 11":

==10135== 
==10135== HEAP SUMMARY:
==10135==     in use at exit: 38,675 bytes in 49 blocks
==10135==   total heap usage: 1,818 allocs, 1,769 frees, 185,163 bytes allocated
==10135== 
==10135== LEAK SUMMARY:
==10135==    definitely lost: 0 bytes in 0 blocks
==10135==    indirectly lost: 0 bytes in 0 blocks
==10135==      possibly lost: 0 bytes in 0 blocks
==10135==    still reachable: 38,675 bytes in 49 blocks
==10135==         suppressed: 0 bytes in 0 blocks
==10135== Reachable blocks (those to which a pointer was found) are not shown.
==10135== To see them, rerun with: --leak-check=full --show-reachable=yes
==10135== 
==10135== For counts of detected and suppressed errors, rerun with: -v
==10135== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 18 from 8)
==10135== 
==10135== Process terminating with default action of signal 11 (SIGSEGV)
==10135==  Bad permissions for mapped region at address 0x4001245
==10135==    at 0x10C630: _dl_lookup_symbol_x (dl-lookup.c:713)
==10135==    by 0x1174EF: _dl_runtime_resolve (dl-trampoline.S:37)
==10135==    by 0x1FE457: mmap (mmap.S:62)
==10135==    by 0x808E635: remove_from_io_select (dosemu_debug.h:188)
==10135==    by 0x808DAB9: ??? (mapfile.c:208)
==10135==    by 0x80E4FB9: low_mem_init (unistd.h:45)
==10135==    by 0x805E2D4: redraw_cursor (text.c:180)
==10135==    by 0x13CE15: (below main) (libc-start.c:226)
==10135== 
==10135== HEAP SUMMARY:
==10135==     in use at exit: 95,850 bytes in 492 blocks
==10135==   total heap usage: 1,938 allocs, 1,446 frees, 279,383 bytes allocated
==10135== 
==10135== LEAK SUMMARY:
==10135==    definitely lost: 0 bytes in 0 blocks
==10135==    indirectly lost: 0 bytes in 0 blocks
==10135==      possibly lost: 0 bytes in 0 blocks
==10135==    still reachable: 95,850 bytes in 492 blocks
==10135==         suppressed: 0 bytes in 0 blocks
==10135== Reachable blocks (those to which a pointer was found) are not shown.
==10135== To see them, rerun with: --leak-check=full --show-reachable=yes
==10135== 
==10135== For counts of detected and suppressed errors, rerun with: -v
==10135== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 25 from 10)

Ten kousek:

==10135==  Bad permissions for mapped region at address 0x4001245
==10135==    at 0x10C630: _dl_lookup_symbol_x (dl-lookup.c:713)
==10135==    by 0x1174EF: _dl_runtime_resolve (dl-trampoline.S:37)
==10135==    by 0x1FE457: mmap (mmap.S:62)
==10135==    by 0x808E635: remove_from_io_select (dosemu_debug.h:188)
==10135==    by 0x808DAB9: ??? (mapfile.c:208)
==10135==    by 0x80E4FB9: low_mem_init (unistd.h:45)
==10135==    by 0x805E2D4: redraw_cursor (text.c:180)
==10135==    by 0x13CE15: (below main) (libc-start.c:226)

je zajímavý, ale jak jej interpretovat?

[l4m4]

Chce to asi zjistit, kde se vzala ta oblast paměti na 0x4001245, pak možná bude vidět, proč má špatná práva.

U běžícího procesu se lze podívat do /proc/$PID/maps, u zdechlého to snad GDB taky umí, ale nevím jak.

[rastos]

u zdechlého to snad GDB taky umí, ale nevím jak.

Cez ulimit povoliť vytváranie "core" súboru (nejak sa stalo zvykom to zakazovať). A potom v gdb povedať, že má použiť ten core súbor.

Franta: pokiaľ si spokojný z riešením od Voty, tak ho označ ako riešenie.

[Franta Hanzlík]

Ahoj, díky za pomoc a omlouvám se za amatérské dotazy. Co se týká toho "Bad permissions for mapped region", nemohlo to pojít od toho, že program na několik svých oblastí předtím volal mprotect() včetně PROT_NONE a že pokud nemají stránky default permissions tak se to valgrindu nelíbí?

Neprogramuji, a tak asi do toho nebudu dál šťourat, to bych musel začít tvrdě od základů; Votovo řešení je dostačující. Ale - jak jej mám označit za řešení? Není to funkce povolená jen registrovaným? Nebo jsem nějaký čudlík přehlédl?

[rastos]

omlouvám se za amatérské dotazy.

Nie je na to najmenší dôvod.

pokud nemají stránky default permissions tak se to valgrindu nelíbí

Zjavne valgrind vie o mprotect()-e pretože ho podľa zoznamu opravených bugov valgrindu "nejak" ošetruje. Ale či mu to vadí, to netuším.

Ale - jak jej mám označit za řešení? Není to funkce povolená jen registrovaným?

Aha. To máš pravdu

[rastos]

A pak zřejmě někde cyklí, valgrind (na top-u se zobrazuje memcheck-x86-li(nux)) neustále spotřebovává 95-100% CPU a nic se neděje.

To je normálne. Dnes som bežal pod valgrindom program takmer 20 minút, zatiaľ čo bez neho to trvá pod 15 sekúnd. Cieľom je dostať z valgrindu napr. informácie o použití neinicializovaných premenných alebo iné potenciálne zdroje problémov.

Tak ako vravel Michal - podľa toho backtrace-u to vyzerá, že sa tá funkcia hľadá v dynamickej knižnici, ale ty si správne interpretoval to "T", že tá funkcia má skutočne implementáciu (teda svoj "text") v terminal.o. Potom ma ešte napadá, že to terminal.o sa nedostane do tej zdieľanej knižnice, alebo že sa dokonca použije úplne iná knižnica. Môžeš to nm skúsiť nechať zbehnúť na príslušnú knižnicu/exe. Alebo môžeš sledovať, ktoré knižnice to vlastne použije - to môže prezradiť ldd, alebo (ak sa to dá stihnúť) obsah súboru /proc/{pid}/maps.

[Franta Hanzlík]

prdlajs jsem správně interpretoval ;), jen jsem sem pastnul výpis "nm" podle vašeho návodu. Jinak tápu a uvítám další popostrčení. Těch dynamicky loadovaných pluginů jsem se zbavil a překládám je inline (viz jak jsem psal před chvílí výše, padá to stejně i když trochu jinde). Co znamená to "nm nechať zbehnúť na príslušnú knižnicu/exe"? S tím valgrindem jsem také neúspěšný - nechal jsem to běžet přes dvě hodiny, CPU pořád na 100% (naštěstí jen jedno jádro) a kromě oněch cca 10kB jak jsem psal minule už nevypíše nic. Přitom za normálních okolností by měl vytvořit během vteřiny dialogové okno a čekat na uživatelův vstup. ldd na binárku vypíše:

$ ldd /usr/bin/dosemu.bin
	linux-gate.so.1 =>  (0x005b5000)
	libvga.so.1 => /usr/lib/libvga.so.1 (0x0034f000)
	librt.so.1 => /lib/librt.so.1 (0x00343000)
	libdl.so.2 => /lib/libdl.so.2 (0x002bc000)
	libm.so.6 => /lib/libm.so.6 (0x002e1000)
	libslang.so.2 => /usr/lib/libslang.so.2 (0x0077f000)
	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x059c6000)
	libXext.so.6 => /usr/lib/libXext.so.6 (0x00653000)
	libX11.so.6 => /usr/lib/libX11.so.6 (0x00124000)
	libgpm.so.2 => /usr/lib/libgpm.so.2 (0x005fa000)
	libasound.so.2 => /lib/libasound.so.2 (0x06699000)
	libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x05b7c000)
	libSDL-1.2.so.0 => /usr/lib/libSDL-1.2.so.0 (0x0693d000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x002c3000)
	libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00324000)
	libc.so.6 => /lib/libc.so.6 (0x003f1000)
	/lib/ld-linux.so.2 (0x00102000)
	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x0025b000)
	libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x068fe000)
	libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x06786000)
	libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x0644a000)
	libogg.so.0 => /usr/lib/libogg.so.0 (0x06442000)
	libXau.so.6 => /usr/lib/libXau.so.6 (0x005f5000)

nic podezřelého na tom taky nevidím. Nemůže to havarovat někde v glibc syscall rutinách? Napadlo mne i zda si třeba přes ten mprotect() nezakáže (třeba blbým parametrem/voláním) přístup k systémovým voláním a pokus o ně pak neskončí takhle, ale nevím jak to ověřit nebo vyloučit.
Keby som mal pušku...
Ale takhle?

[Jirka P]

Napadlo mne i zda si třeba přes ten mprotect() nezakáže (třeba blbým parametrem/voláním)

Jestli chcete zjistit, co se děje s mapováními, zkuste si přečíst /proc/$PID/maps a použijte strace na ten program.

[asi si ten profil uz vazne zalozim]

Jen tak strelim od boku, treba to pomuze. Pokud to buildite pomoci gcc, zkuste pridat prepinac -rdynamic

[Franta Hanzlík]

Jojo, s gcc. Ale pokud to konfiguruji s dynamicky překládanými pluginy, tak se (asi) vše sestavuje s -rdynamic. Teď když je mám inline, tak ne - ale jak píši výše, problém bude asi někde jinde.