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)