X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/81cb11b0827fcd9e3dc34cce48a07c46b2f6ece4..8516b068ed1b8fa928ffa994440f9b40d21e791c:/doc/FAQ.doc diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 770e02953b..4c78753628 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -107,7 +107,7 @@ cd simgrid ./configure --enable-maintainer-mode make dist \endverbatim -\subsection faq_setting Setting up your own code +\subsection faq_setting_MSG Setting up your own MSG code Do not build your simulator by modifying the SimGrid examples. Go outside the SimGrid source tree and create your own working directory @@ -186,6 +186,12 @@ in a terminal : info make and read the introduction. The previous example should be enough for a first try but you may want to perform some more complex compilations... +\subsection faq_setting_GRAS Setting up your own GRAS code + +If you use the GRAS interface instead of the MSG one, then previous section +is not the better source of information. Instead, you should check the GRAS +tutorial in general, and the \ref GRAS_tut_tour_setup in particular. + \section faq_simgrid I'm new to SimGrid. I have some questions. Where should I start? You are at the right place... Having a look to these @@ -328,7 +334,7 @@ MSG_task_get_name(), MSG_task_get_compute_duration(), MSG_task_get_remaining_computation(), MSG_task_get_data_size(), and MSG_task_get_data(). -You could use a dictionnary (#xbt_dict_t) of dynars (#xbt_dict_t). If +You could use a dictionnary (#xbt_dict_t) of dynars (#xbt_dynar_t). If you still don't see how to do it, please come back to us... \subsection faq_MIA_asynchronous I want to do asynchronous communications in MSG @@ -801,7 +807,7 @@ machine: If none of the above apply, please drop us a mail on the mailing list so that we can check it out. -\subsection faq_longjmp longjmp madness +\subsection faq_longjmp longjmp madness in valgrind This is when valgrind starts complaining about longjmp things, just like: @@ -838,6 +844,52 @@ probably, you have a return; somewhere within a TRY{} block. This is evil, and you must not do this. Did you read the section about \ref XBT_ex?? +\subsection faq_valgrind Valgrind spits tons of errors! + +It may happen that valgrind, the memory debugger beloved by any decent C +programmer, spits tons of warnings like the following : +\verbatim ==8414== Conditional jump or move depends on uninitialised value(s) +==8414== at 0x400882D: (within /lib/ld-2.3.6.so) +==8414== by 0x414EDE9: (within /lib/tls/i686/cmov/libc-2.3.6.so) +==8414== by 0x400B105: (within /lib/ld-2.3.6.so) +==8414== by 0x414F937: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) +==8414== by 0x4150F4C: (within /lib/tls/i686/cmov/libc-2.3.6.so) +==8414== by 0x400B105: (within /lib/ld-2.3.6.so) +==8414== by 0x415102D: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.3.6.so) +==8414== by 0x412D6B9: backtrace (in /lib/tls/i686/cmov/libc-2.3.6.so) +==8414== by 0x8076446: xbt_dictelm_get_ext (dict_elm.c:714) +==8414== by 0x80764C1: xbt_dictelm_get (dict_elm.c:732) +==8414== by 0x8079010: xbt_cfg_register (config.c:208) +==8414== by 0x806821B: MSG_config (msg_config.c:42) +\endverbatim + +This problem is somewhere in the libc when using the backtraces and there is +very few things we can do ourselves to fix it. Instead, here is how to tell +valgrind to ignore the error. Add the following to your ~/.valgrind.supp (or +create this file on need). Make sure to change the obj line according to +your personnal mileage (change 2.3.6 to the actual version you are using, +which you can retrieve with a simple "ls /lib/ld*.so"). + +\verbatim { + name: Backtrace madness + Memcheck:Cond + obj:/lib/ld-2.3.6.so + fun:dl_open_worker + fun:_dl_open + fun:do_dlopen + fun:dlerror_run + fun:__libc_dlopen_mode +}\endverbatim + +Then, you have to specify valgrind to use this suppression file by passing +the --suppressions=$HOME/.valgrind.supp option on the command line. +You can also add the following to your ~/.bashrc so that it gets passed +automatically. Actually, it passes a bit more options to valgrind, and this +happen to be my personnal settings. Check the valgrind documentation for +more information. + +\verbatim export VALGRIND_OPTS="--leak-check=yes --leak-resolution=high --num-callers=40 --tool=memcheck --suppressions=$HOME/.valgrind.supp" \endverbatim + \subsection faq_flexml_limit I get the message "surf_parse_lex: Assertion `next<limit' failed." This is because your platform file is too big for the parser. @@ -914,52 +966,6 @@ reason: before the client get a chance to read them (use gras_os_sleep() to delay the server), or the server died awfully before the client got the data. -\subsection faq_valgrind Valgrind spits tons of errors! - -It may happen that valgrind, the memory debugger beloved by any decent C -programmer, spits tons of warnings like the following : -\verbatim ==8414== Conditional jump or move depends on uninitialised value(s) -==8414== at 0x400882D: (within /lib/ld-2.3.6.so) -==8414== by 0x414EDE9: (within /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x400B105: (within /lib/ld-2.3.6.so) -==8414== by 0x414F937: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x4150F4C: (within /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x400B105: (within /lib/ld-2.3.6.so) -==8414== by 0x415102D: __libc_dlopen_mode (in /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x412D6B9: backtrace (in /lib/tls/i686/cmov/libc-2.3.6.so) -==8414== by 0x8076446: xbt_dictelm_get_ext (dict_elm.c:714) -==8414== by 0x80764C1: xbt_dictelm_get (dict_elm.c:732) -==8414== by 0x8079010: xbt_cfg_register (config.c:208) -==8414== by 0x806821B: MSG_config (msg_config.c:42) -\endverbatim - -This problem is somewhere in the libc when using the backtraces and there is -very few things we can do ourselves to fix it. Instead, here is how to tell -valgrind to ignore the error. Add the following to your ~/.valgrind.supp (or -create this file on need). Make sure to change the obj line according to -your personnal mileage (change 2.3.6 to the actual version you are using, -which you can retrieve with a simple "ls /lib/ld*.so"). - -\verbatim { - name: Backtrace madness - Memcheck:Cond - obj:/lib/ld-2.3.6.so - fun:dl_open_worker - fun:_dl_open - fun:do_dlopen - fun:dlerror_run - fun:__libc_dlopen_mode -}\endverbatim - -Then, you have to specify valgrind to use this suppression file by passing -the --suppressions=$HOME/.valgrind.supp option on the command line. -You can also add the following to your ~/.bashrc so that it gets passed -automatically. Actually, it passes a bit more options to valgrind, and this -happen to be my personnal settings. Check the valgrind documentation for -more information. - -\verbatim export VALGRIND_OPTS="--leak-check=yes --leak-resolution=high --num-callers=40 --tool=memcheck --suppressions=$HOME/.valgrind.supp" \endverbatim - \subsection faq_deadlock There is a deadlock !!! Unfortunately, we cannot debug every code written in SimGrid. We @@ -985,7 +991,26 @@ valuer greater than 1: \endverbatim You should try to use the surfxml_update.pl script that can be found here. - + +\subsection faq_bugrepport So I've found a bug in SimGrid. How to repport it? + +We do our best to make sure to hammer away any bugs of SimGrid, but this is +still an academic project so please be patient if/when you find bugs in it. +If you do, the best solution is to drop an email either on the simgrid-user +or the simgrid-devel mailing list and explain us about the issue. You can +also decide to open a formal bug report using the +relevant +interface. You need to login on the server to get the ability to submit +bugs. + +We will do our best to solve any problem repported, but you need to help us +finding the issue. Just telling "it segfault" isn't enough. Telling "It +segfaults when running the attached simulator" doesn't really help either. +You may find the following article interesting to see how to repport +informative bug repports: +http://www.chiark.greenend.org.uk/~sgtatham/bugs.html (it is not SimGrid +specific at all, but it's full of good advices). + \author Arnaud Legrand (arnaud.legrand::imag.fr) \author Martin Quinson (martin.quinson::loria.fr)