trivial, and that data do not following the shortest path in number of
hops on this graph. Another way to say it is that there is no implicit
in these routing descriptions. The system will only use the routes you
-declare (such as <route src="A" dst="C"><route_element
-name="3"/></route>), without trying to build new routes by aggregating
+declare (such as <route src="A" dst="C"><route_element
+name="3"/></route>), without trying to build new routes by aggregating
the provided ones.
You are also free to declare platform where the routing is not
\section faq_troubleshooting Troubleshooting
-\subsection faq_trouble_compil Compilation and installation problems
+\subsection faq_trouble_lib_compil SimGrid compilation and installation problems
-\subsubsection faq_trouble_config ./configure fails!
+\subsubsection faq_trouble_lib_config ./configure fails!
We now only one reason for the configure to fail:
that we can check it out. Make sure to read \ref faq_bugrepport
before you do so.
-\subsection faq_trouble_errors Understanding error messages
+\subsection faq_trouble_compil User code compilation problems
\subsubsection faq_trouble_err_logcat "gcc: _simgrid_this_log_category_does_not_exist__??? undeclared (first use in this function)"
for all the details, but you simply forgot to call one of
XBT_LOG_NEW_DEFAULT_CATEGORY() or XBT_LOG_NEW_DEFAULT_SUBCATEGORY().
+\subsubsection faq_trouble_pthreadstatic "gcc: undefinded reference to pthread_key_create"
+
+This indicates that one of the library SimGrid depends on (libpthread
+here) was missing on the linking command line. Dependencies of
+libsimgrid are expressed directly in the dynamic library, so it's
+quite impossible that you see this message when doing dynamic linking.
+
+If you compile your code statically (and if you use a pthread version
+of SimGrid -- see \ref faq_more_processes), you must absolutely
+specify <tt>-lpthread</tt> on the linker command line. As usual, this should
+come after <tt>-lsimgrid</tt> on this command line.
+
+\subsection faq_trouble_errors Runtime error messages
+
\subsubsection faq_flexml_limit "surf_parse_lex: Assertion `next limit' failed."
This is because your platform file is too big for the parser.
If you don't, you really should use valgrind to debug your code, it's
almost magic.
+\subsubsection faq_trouble_vg_context Stack switching problems and truncated backtraces
+
+With the default version of simgrid, valgrind will probably spit tons
+of warnings about stack switching like the following, and produce
+truncated bactraces where only one call appears instead of the whole
+stack.
+
+\verbatim
+==14908== Warning: client switching stacks? SP change: 0xBEA2A48C --> 0x476F350
+==14908== to suppress, use: --max-stackframe=1171541700 or greater
+==14908== Warning: client switching stacks? SP change: 0x476E1E4 --> 0xBEA2A48C
+==14908== to suppress, use: --max-stackframe=1171537240 or greater
+==14908== Warning: client switching stacks? SP change: 0xBEA2A48C --> 0x4792420
+==14908== to suppress, use: --max-stackframe=1171685268 or greater
+==14908== further instances of this message will not be shown.
+\endverbatim
+
+This is because valgrind don't like too much the UNIX98 contextes we
+use by default in simgrid for efficiency reasons. Simply add the
+--with-pthread flag to your configure when debugging your code. You
+may also find --disable-compiler-optimization usefull 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 third of the true SimGrid potential.
+
\subsubsection faq_trouble_vg_longjmp longjmp madness in valgrind
This is when valgrind starts complaining about longjmp things, just like:
