X-Git-Url: http://info.iut-bm.univ-fcomte.fr/pub/gitweb/simgrid.git/blobdiff_plain/b7ace14cb46a13419c4e499d8d012aad0a6510e6..1095cadacd735f79bded966f30b4d6ebb1cf13ab:/doc/FAQ.doc diff --git a/doc/FAQ.doc b/doc/FAQ.doc index 3f6aacedae..020d580c94 100644 --- a/doc/FAQ.doc +++ b/doc/FAQ.doc @@ -11,8 +11,10 @@ not familiar with compiling C files under UNIX. If you follow these instructions and still have some troubles, drop an e-mail to . -\subsection faq_compiling Compiling SimGrid +\subsection faq_compiling Compiling SimGrid from an archive +First of all, you need to download the latest version of SimGrid from +here. Suppose you have uncompressed SimGrid in some temporary location of your home directory (say /home/joe/tmp/simgrid-3.0.1 ). The simplest way to use SimGrid is to install it in your home @@ -63,6 +65,48 @@ Thus, there is two ways to link your program with SimGrid: \verbatim export LD_LIBRARY_PATH=$HOME/lib/:$LD_LIBRARY_PATH \endverbatim + +\subsection faq_compiling_cvs Compiling SimGrid from the CVS + +The project development takes place in the cvs, where all changes are +commited when they happen. Then every once in a while, we make sure that the +code quality meets our standard and release an archive from the code in the +CVS. We afterward go back to the development in the CVS. So, if you need a +recently added feature and can afford some little problem with the stability +of the lastest features, you may want to use the CVS version instead of a +released one. + +For that, you first need to get the "simgrid" module from +here. + +You won't find any configure and a few other things +(Makefile.in's, documentation, ...) will be missing as well. The +reason for that is that all these files have to be regenerated using the +latest versions of autoconf, libtool, automake +(>1.9) and doxygen (>1.4). To generate the configure and +the Makefile.in's, you just have to launch the bootstrap +command that resides in the top of the source tree. Then just follow the +instructions of Section \ref faq_compiling. + +We insist on the fact that you really need the latest versions of +autoconf and automake. Doing this step on exotic architectures/systems +(i.e. anything different from a recent linux distribution) may be +... uncertain. If you want to use the CVS version on another +architecture/system, you should do the previous steps on a perfectly +standard box, then do a make dist that will build you a +perfectly portable SimGrid archive. + +In summary, the following commands will checkout the CVS, regenerate the +configure script and friends, configure SimGrid and build an archive you can +use on another machine afterward. + +\verbatim cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid login +cvs -d :pserver:anonymous@scm.gforge.inria.fr:/cvsroot/simgrid checkout simgrid +cd simgrid +./bootstrap +./configure --enable-maintainer-mode +make dist \endverbatim + \subsection faq_setting Setting up your own code Do not build your simulator by modifying the SimGrid examples. Go @@ -145,7 +189,9 @@ perform some more complex compilations... \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 -slides +slides +(or to these +"obsolete" slides) may give you some insights on what SimGrid can help you to do and what are its limitations. Then you definitely should read the \ref MSG_examples. There is also a mailing list: . @@ -794,7 +840,8 @@ Here are some tricks I had to use in order to run a token ring between - It was really boring to write 25,000 entries in the deployment file, so I wrote a little script examples/gras/tokenS/make_deployment.pl, which you may - want to adapt to your case. + want to adapt to your case. You could also think about hijacking + the SURFXML parser (have look at \ref faq_flexml_bypassing). - The deployment file became quite big, so I had to do what is in the FAQ entry \ref faq_flexml_limit @@ -808,6 +855,43 @@ Here are some tricks I had to use in order to run a token ring between low, you'll get a segfault. The token ring example, which is quite simple, runs with 40kb stacks. +\subsection faq_longjmp longjmp madness + +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 + +or even when it reports scary things like: + +\verbatim ==24023== Warning: client switching stacks? SP change: 0xBE3FF618 --> 0xBE7FF710 +x86->IR: unhandled instruction bytes: 0xF4 0xC7 0x83 0xD0 +==24023== to suppress, use: --max-stackframe=4194552 or greater +==24023== Your program just tried to execute an instruction that Valgrind +==24023== did not recognise. There are two possible reasons for this. +==24023== 1. Your program has a bug and erroneously jumped to a non-code +==24023== location. If you are running Memcheck and you just saw a +==24023== warning about a bad jump, it's probably your program's fault. +==24023== 2. The instruction is legitimate but Valgrind doesn't handle it, +==24023== i.e. it's Valgrind's fault. If you think this is the case or +==24023== you are not sure, please let us know. +==24023== Either way, Valgrind will now raise a SIGILL signal which will +==24023== probably kill your program. +==24023== +==24023== Process terminating with default action of signal 4 (SIGILL) +==24023== Illegal opcode at address 0x420D234 +==24023== at 0x420D234: abort (abort.c:124) +\endverbatim + +This is the sign that you didn't used the exception mecanism well. Most +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_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. @@ -844,6 +928,47 @@ These are changes to FleXML itself, not SimGrid. But since we kinda hijacked the development of FleXML, I can grant you that any patches would be really welcome and quickly integrated. +\subsection faq_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: + + - Transport endpoint is not connected: 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. + + - Socket closed by remote side: if the remote process is not + supposed to close the socket at this point, it may be dead. + + - Connection reset by peer: I found this on internet about this + error. I think it's what's happening here, too:\n + 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.\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. + + \subsection faq_deadlock There is a deadlock !!! Unfortunately, we cannot debug every code written in SimGrid. We