Logo AND Algorithmique Numérique Distribuée

Public GIT Repository
This output may be interesting
[simgrid.git] / doc / FAQ.doc
index d57322e..4c78753 100644 (file)
@@ -107,7 +107,7 @@ cd simgrid
 ./configure --enable-maintainer-mode
 make dist \endverbatim
 
 ./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
 
 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 : <tt>info make</tt> and read the introduction. The
 previous example should be enough for a first try but you may want to
 perform some more complex compilations...
 
 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
 \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
@@ -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.
 
    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:
 
 
 This is when valgrind starts complaining about longjmp things, just like:
 
@@ -838,6 +844,52 @@ probably, you have a <tt>return;</tt> somewhere within a <tt>TRY{}</tt>
 block. This is <b>evil</b>, and you must not do this. Did you read the section
 about \ref XBT_ex??
 
 block. This is <b>evil</b>, 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 <tt>--suppressions=$HOME/.valgrind.supp</tt> 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&lt;limit' failed."
 
 This is because your platform file is too big for the parser. 
 \subsection faq_flexml_limit I get the message "surf_parse_lex: Assertion `next&lt;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.
 
    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 <tt>--suppressions=$HOME/.valgrind.supp</tt> 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
 \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
 <a href="http://gforge.inria.fr/plugins/scmcvs/cvsweb.php/contrib/platform_generation/?cvsroot=cvsroot%2Fsimgrid">here</a>.
 \endverbatim
 You should try to use the surfxml_update.pl script that can be found
 <a href="http://gforge.inria.fr/plugins/scmcvs/cvsweb.php/contrib/platform_generation/?cvsroot=cvsroot%2Fsimgrid">here</a>.
-  
+
+\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
+<a href="https://gforge.inria.fr/tracker/?atid=165&group_id=12&func=browse">relevant
+interface</a>. 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)
 
 \author Arnaud Legrand (arnaud.legrand::imag.fr)
 \author Martin Quinson (martin.quinson::loria.fr)