+<b>Update:</b> A new version of FleXML (1.7) was released. Most of the work
+was done by William Dowling, who use it in his own work. The good point is
+that it now use a dynamic buffer, and that the memory usage was greatly
+improved. The downside is that William also changed some things internally,
+and it breaks the hack we devised to bypass the parser, as explained in
+\ref faq_flexml_bypassing. Indeed, this is not a classical usage of the
+parser, and Will didn't imagine that we may have used (and even documented)
+such a crude usage of FleXML. So, we now have to repare the bypassing
+functionnality to use the lastest FleXML version and fix the memory usage in
+SimGrid.
+
+\subsubsection faq_trouble_gras_transport GRAS spits networking error messages
+
+Gras, on real platforms, naturally use regular sockets to communicate. They
+are deeply hiden in the gras abstraction, but when things go wrong, you may
+get some weird error messages. Here are some example, with the probable
+reason:
+
+ - <b>Transport endpoint is not connected</b>: several processes try to open
+ a server socket on the same port number of the same machine. This is
+ naturally bad and each process should pick its own port number for this.\n
+ Maybe, you just have some processes remaining from a previous experiment
+ on your machine.\n
+ Killing them may help, but again if you kill -KILL them, you'll have to
+ wait for a while: they didn't close there sockets properly and the system
+ needs a while to notice that this port is free again.
+
+ - <b>Socket closed by remote side</b>: if the remote process is not
+ supposed to close the socket at this point, it may be dead.
+
+ - <b>Connection reset by peer</b>: I found this on internet about this
+ error. I think it's what's happening here, too:\n
+ <i>This basically means that a network error occurred while the client was
+ receiving data from the server. But what is really happening is that the
+ server actually accepts the connection, processes the request, and sends
+ a reply to the client. However, when the server closes the socket, the
+ client believes that the connection has been terminated abnormally
+ because the socket implementation sends a TCP reset segment telling the
+ client to throw away the data and report an error.\n
+ Sometimes, this problem is caused by not properly closing the
+ input/output streams and the socket connection. Make sure you close the
+ input/output streams and socket connection properly. If everything is
+ closed properly, however, and the problem persists, you can work around
+ it by adding a one-second sleep before closing the streams and the
+ socket. This technique, however, is not reliable and may not work on all
+ systems.</i>\n
+ Since GRAS sockets are closed properly (repeat after me: there is no bug
+ in GRAS), it is either that you are closing your sockets on server side
+ 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.
+
+\subsubsection faq_trouble_errors_big_fat_warning I'm told that my XML files are too old.
+
+The format of the XML platform description files is sometimes
+improved. For example, we decided to change the units used in SimGrid
+from MBytes, MFlops and seconds to Bytes, Flops and seconds to ease
+people exchanging small messages. We also reworked the route
+descriptions to allow more compact descriptions.
+
+That is why the XML files are versionned using the 'version' attribute
+of the root tag. Currently, it should read:
+\verbatim
+ <platform version="2">
+\endverbatim
+
+If your files are too old, you can use the simgrid_update_xml.pl
+script which can be found in the tools directory of the archive.
+
+\subsection faq_trouble_valgrind Valgrind-related and other debugger issues
+
+If you don't, you really should use valgrind to debug your code, it's
+almost magic.
+
+\subsubsection faq_trouble_vg_longjmp longjmp madness in valgrind
+
+This is when valgrind starts complaining about longjmp things, just like:
+
+\verbatim ==21434== Conditional jump or move depends on uninitialised value(s)
+==21434== at 0x420DBE5: longjmp (longjmp.c:33)
+==21434==
+==21434== Use of uninitialised value of size 4
+==21434== at 0x420DC3A: __longjmp (__longjmp.S:48)
+\endverbatim
+
+This is the sign that you didn't used the exception mecanism well. Most
+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??
+
+\subsubsection faq_trouble_vg_libc Valgrind spits tons of errors about backtraces!
+
+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
+
+\subsubsection faq_trouble_backtraces Truncated backtraces
+
+When debugging SimGrid, it's easier to pass the
+--disable-compiler-optimization flag to the configure if valgrind or
+gdb get fooled by the optimization done by the compiler. But you
+should remove these flages when everything works before going in
+production (before launching your 1252135 experiments), or everything
+will run only one half of the true SimGrid potential.
+
+\subsection faq_deadlock There is a deadlock in my code!!!
+
+Unfortunately, we cannot debug every code written in SimGrid. We
+furthermore believe that the framework provides ways enough
+information to debug such informations yourself. If the textual output
+is not enough, Make sure to check the \ref faq_visualization FAQ entry to see
+how to get a graphical one.
+
+Now, if you come up with a really simple example that deadlocks and
+you're absolutely convinced that it should not, you can ask on the
+list. Just be aware that you'll be severely punished if the mistake is
+on your side... We have plenty of FAQ entries to redact and new
+features to implement for the impenitents! ;)
+
+\subsection faq_surf_network_latency I get weird timings when I play with the latencies.
+
+OK, first of all, remember that units should be Bytes, Flops and
+Seconds. If you don't use such units, some SimGrid constants (e.g. the
+SG_TCP_CTE_GAMMA constant used in most network models) won't have the
+right unit and you'll end up with weird results.
+
+Here is what happens with a single transfer of size L on a link
+(bw,lat) when nothing else happens.
+
+\verbatim
+0-----lat--------------------------------------------------t
+|-----|**** real_bw =min(bw,SG_TCP_CTE_GAMMA/(2*lat)) *****|
+\endverbatim
+
+In more complex situations, this min is the solution of a complex
+max-min linear system. Have a look
+<a href="http://lists.gforge.inria.fr/pipermail/simgrid-devel/2006-April/thread.html">here</a>
+and read the two threads "Bug in SURF?" and "Surf bug not
+fixed?". You'll have a few other examples of such computations. You
+can also read "A Network Model for Simulation of Grid Application" by
+Henri Casanova and Loris Marchal to have all the details. The fact
+that the real_bw is smaller than bw is easy to understand. The fact
+that real_bw is smaller than SG_TCP_CTE_GAMMA/(2*lat) is due to the
+window-based congestion mechanism of TCP. With TCP, you can't exploit
+your huge network capacity if you don't have a good round-trip-time
+because of the acks...
+
+Anyway, what you get is t=lat + L/min(bw,SG_TCP_CTE_GAMMA/(2*lat)).
+
+ * if I you set (bw,lat)=(100 000 000, 0.00001), you get t = 1.00001 (you fully
+use your link)
+ * if I you set (bw,lat)=(100 000 000, 0.0001), you get t = 1.0001 (you're on the
+limit)
+ * if I you set (bw,lat)=(100 000 000, 0.001), you get t = 10.001 (ouch!)
+
+This bound on the effective bandwidth of a flow is not the only thing
+that may make your result be unexpected. For example, two flows
+competing on a saturated link receive an amount of bandwidth inversely
+proportional to their round trip time.
+
+\subsection faq_bugrepport So I've found a bug in SimGrid. How to report 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)