05/01/12 17:12
Pitagora
Penso che sia quello che serve a te:
crashes under Linux/Unix
When your Allegro compiled Linux/Unix program crashes, you will usually get a not very meaningful message along with a core dump:
Shutting down Allegro due to signal #11
Segment violation (core dumped)
Look at your filesystem: there should be a file named core or something similar with information telling you exactly where the crash occurred. If there is no core, check your environment settings, under bash this is done with the 'ulimit -a' command. Usually 'ulimit -c unlimited' somewhere in your login scripts should work fine.
Just like with djgpp, to make sense of the core, you should compile your program with debugging information (using the -g switch), and then run the GNU debugger on it "gdb binary core". That will load the debugger, print some information about linked libraries and leave you at a prompt. Now you can get the full backtrace:
(gdb) backtrace
#0 0x08065237 in utf8_getx (s=0xbffffc5c) at ./src/unicode.c:347
#1 0x0806953f in ustrzcpy (dest=0x0, size=2147483646, src=0x0) at ./src/unicode.c:1770
#2 0x08057575 in _mangled_main () at t.c:9
#3 0x0806c9bf in main (argc=1, argv=0xbffffd14) at ./src/unix/umain.c:39
#4 0x4015414f in __libc_start_main () from /lib/libc.so.6
In this case, you can see that the crash occurred in the ustrzcpy() function, which was called at line 9 of the main() function in the t.c source file. Now you just have to go to that line, have a look at whatever you are doing there, and change it to be correct :-)
Note that the crash happened deep inside an Allegro function, which is also revealed by the traceback. However, the binary was linked against a static debug version of Allegro, we wouldn't have had so much luck with a non debug or dynamically linked version.
Since gdb is an interactive debugger, you could also select a frame and check out the values of the variables, to see better who is the culprit:
(gdb) frame 2
#2 0x08057575 in _mangled_main () at t.c:9
9 ustrcpy(p1, p2);
(gdb) list
4
5 int main(void)
6 {
7 char *p1 = 0, *p2 = 0;
8 allegro_init();
9 ustrcpy(p1, p2);
10 return 0;
11 }
12 END_OF_MAIN()
(gdb) print p1
= 0x0
(gdb) print p2
= 0x0
Yuck! Playing with NULL values doesn't really pay off. Ok, while this was a slightly out-of-the-can example, you surely get the point. Remember to check out GDB's manual to learn about more useful commands and/or how to debug your program while it's running and many other things. You might also want to check out Peter Wang's "Debugging with GDB" article, featured in the ninth number of the Pixelate online magazine (http://pixwiki.bafsoft.com/).
... Se poi rendi pubblico il codice
Ultima modifica effettuata da Pitagora 05/01/12 17:13
aaa
05/01/12 18:44
Nullable
Io non so aiutarti in questo, scrivo questo post per correggerti : allegro.h è un file di intestazione ( header ) non una libreria ( le librerie sono o statiche [.lib] o dinamiche [.dll] ).
aaa
sarbaturino
