./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
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
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.
+\subsection faq_MIA_asynchronous I want to do asynchronous communications in MSG
Up until now, there is no asynchronous communications in MSG. However,
you can create as many process as you want so you should be able to do
process only to handle communications may be problematic in term of
performance at some point). I'll add it in the distribution asap.
-\subsection faq_MIA_thread_synchronization I need to synchronize my processes
+\subsection faq_MIA_thread_synchronization I need to synchronize my MSG processes
You obviously cannot use pthread_mutexes of pthread_conds. The best
thing would be to propose similar structures. Unfortunately, we
\subsection faq_SG_DAG How to implement a distributed dynamic scheduler of DAGs.
Distributed is somehow "contagious". If you start making distributed
-decisions, there is no way to handle DAGs directly anymore (unless I am
-missing something). You have to encode your DAGs in term of communicating
-process to make the whole scheduling process distributed. Believe me, it is
-worth the effort since you'll then be able to try your algorithms in a very
-wide variety of conditions. Here is an example of how you could do that.
-Assume T1 has to be done before T2.
+decisions, there is no way to handle DAGs directly anymore (unless I
+am missing something). You have to encode your DAGs in term of
+communicating process to make the whole scheduling process
+distributed. Here is an example of how you could do that. Assume T1
+has to be done before T2.
\verbatim
int your_agent(int argc, char *argv[] {
\endverbatim
If you decide that the distributed part is not that much important and that
-DAG is really the level of abstraction you want to work with (but it
-prevents you from having "realistic" platform modeling), then you should
-keep using the 2.18.5 versions until somebody has ported SG on top of SURF.
-Note however that SURF will be slower than the old SG to handle traces with
-a lots of variations (there is no trace integration anymore).
+DAG is really the level of abstraction you want to work with, then you should
+give a try to \ref SD_API.
\section faq_dynamic Dynamic resources and platform building
An example of this trick is distributed in the file examples/msg/msg_test_surfxml_bypassed.c
-\section faq_troubleshooting Troubleshooting
-
-\subsection faq_compil_trouble ./configure fails!
-
-We now only one reason for the configure to fail:
-
- - <b>You are using a borken build environment</b>\n
- If symptom is that configure complains about gcc not being able to build
- executables, you are probably missing the libc6-dev package. Damn Ubuntu.
-
-If you experience other kind of issue, please get in touch with us. We are
-always interested in improving our portability to new systems.
-
-\subsection faq_distcheck_fails Dude! "make check" fails on my machine!
-
-Don't assume we never run this target, because we do. Really. Promise!
-
-There is several reasons which may cause the make check to fail on your
-machine:
-
- - <b>You are using a borken libc (probably concerning the contextes)</b>.\n
- The symptom is that the "make check" fails within the examples/msg directory.\n
- By default, SimGrid uses something called ucontexts. This is part of the
- libc, but it's quite undertested. For example, some (old) versions of the
- glibc on alpha do not implement these functions, but provide the stubs
- (which return ENOSYS: not implemented). It fools our detection mecanism
- and leads to segfaults.\n
- On some x86_64, the pointer to function is stored into a integer, but int
- are 32bits only on this arch while pointers are 64bits. Our detection
- mecanism also fails to detect the problem, which leads to segfaults.\n
- In both cases, there is not much we can do to fix the bug. We are working
- on a workaround for x86_64 machines, but in the meanwhile, you can
- compile with --with-context=pthread to avoid ucontext completely. You'll
- be a bit more limitated in the number of simulated processes you can start
- concurently, but 5000 processes is still enough for most purposes, isn't
- it?\n
- This limitation is the reason why we insist on using this piece of ...
- software even if it's so troublesome.\n
- <b>=> use --with-pthread on AMD64 architecture that do not have an
- ultra-recent libc.</b>
-
- - <b>There is a bug in SimGrid we aren't aware of</b>.\n
- If none of the above apply, please drop us a mail on the mailing list so
- that we can check it out.
+\section faq_limits Pushing the limits
\subsection faq_context_1000 I want thousands of simulated processes
low, you'll get a segfault. The token ring example, which is quite simple,
runs with 40kb stacks.
-\subsection faq_longjmp longjmp madness
+\section faq_troubleshooting Troubleshooting
+
+\subsection faq_compil_trouble ./configure fails!
+
+We now only one reason for the configure to fail:
+
+ - <b>You are using a borken build environment</b>\n
+ If symptom is that configure complains about gcc not being able to build
+ executables, you are probably missing the libc6-dev package. Damn Ubuntu.
+
+If you experience other kind of issue, please get in touch with us. We are
+always interested in improving our portability to new systems.
+
+\subsection faq_distcheck_fails Dude! "make check" fails on my machine!
+
+Don't assume we never run this target, because we do. Really. Promise!
+
+There is several reasons which may cause the make check to fail on your
+machine:
+
+ - <b>You are using a borken libc (probably concerning the contextes)</b>.\n
+ The symptom is that the "make check" fails within the examples/msg directory.\n
+ By default, SimGrid uses something called ucontexts. This is part of the
+ libc, but it's quite undertested. For example, some (old) versions of the
+ glibc on alpha do not implement these functions, but provide the stubs
+ (which return ENOSYS: not implemented). It fools our detection mecanism
+ and leads to segfaults.\n
+ On some x86_64, the pointer to function is stored into a integer, but int
+ are 32bits only on this arch while pointers are 64bits. Our detection
+ mecanism also fails to detect the problem, which leads to segfaults.\n
+ In both cases, there is not much we can do to fix the bug. We are working
+ on a workaround for x86_64 machines, but in the meanwhile, you can
+ compile with --with-context=pthread to avoid ucontext completely. You'll
+ be a bit more limitated in the number of simulated processes you can start
+ concurently, but 5000 processes is still enough for most purposes, isn't
+ it?\n
+ This limitation is the reason why we insist on using this piece of ...
+ software even if it's so troublesome.\n
+ <b>=> use --with-pthread on AMD64 architecture that do not have an
+ ultra-recent libc.</b>
+
+ - <b>There is a bug in SimGrid we aren't aware of</b>.\n
+ 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 in valgrind
This is when valgrind starts complaining about longjmp things, just like:
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<limit' failed."
This is because your platform file is too big for the parser.
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_deadlock There is a deadlock !!!
Unfortunately, we cannot debug every code written in SimGrid. We
\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)
