Hello I've tried to reproduce the bug with an XML archive : nothing happens there. So only a text_archive triggers it. I've also examined the text output, but nothing seems really obvious, it just seems that after the 512 characters garbage is loaded into the std::string (something present earlier in the string); For example If my saved string was: Abalvqdslfldls****************tons of other characters *********** this is the 512th character HERE___and there it is beyond 512 The reloaded string before the next load which will crash will look something like: Abalvqdslfldls****************tons of other characters *********** this is the 512th character HEREons of other characters Or: Abalvqdslfldls****************tons of other characters *********** this is the 512th character HERE Abalvqdslfldls********* I will try to investigate more on this, but nothing is obvious. About the stream buffers, I am not really knowledgeable on this but from what I've read you cannot change the size of the stream buffer used (there is an overloaded method pubsetbuf but the standard says that behaviour is not defined if its arguments are something other than 0,0). So what do you mean? I will tomorrow try to read the file first into a string stream and try to load from there using a text archive. We will see if the bug happens Jean-Noël Without being able to reproduce it its going to be tough for me to find the problem or know when its fixed. try the following a) try using a different stream buffer - strstream b) try changing the size of the streambuffer used c) try xml_serialization d) examine the text output where the load fails to see if there's anything obvious there You've made some progress - but not enough for me to work with. Robert Ramey "RIVASSEAU Jean Noel" <JN.RIVASSEAU@oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04C1E144@naserv31.nanterre.oberthurcs.com... Hi I have tested with a binary archive and the problem does not occur. Only text archives seem to trigger it (I have not yet tested XML archives). I have replaced all "strange" (non-letters) characters and the problem still happens. So the string contains only letters, I even removed the spaces. However do not forget that I left the line breaks in it (if I remove the line breaks, the problem does not appear). To recapitulate: the problem appears when *all* of the following conditions are met: * using a text archive * using a std::string with line breaks * with a length >=512 * * And even like that, I am not able to reproduce this bug in a small program, although in my program it is triggered all the time. Now, Robert, if you could look into that, I'd appreciate it... Jean-Noël _____ De : boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] De la part de Robert Ramey Envoyé : mercredi 1 février 2006 18:13 À : boost-users@lists.boost.org Objet : Re: [Boost-users] [Serialization]: bug while serializing astd:string This sounds like a bug to me. To help me out - check the following: try different types of archives xml, binary, etc. xml archives have a pending issue if a string contains a character (e.g. '\0') which is not representable in an xml string. Other archive classes don't have this problem. Check to see if its related to a particular character. be sure its really question of size. Robert Ramey "RIVASSEAU Jean Noel" <JN.RIVASSEAU@oberthurcs.com> wrote in message news:87F60F7FA02FF749AFB02BD9FCAA6B04C1D8FA@naserv31.nanterre.oberthurcs.com... Hello It seems I have come against a bug in the BSL. I am running on Win 2000 Pro, MinGW (gcc 3.4.2), Boost 1.33.1. If I serialize a standard string with 512 or more characters, the save goes ok but a stream error exception occurs while trying to reload it later from archive. Any string with size < 512 is ok. Also this bug is really strange. It does not happen if the string has no line breaks in it (even if it is more than 512 chars). It also happens on my program, but I was unable to reproduce it with a small test program, even using the same string. Could it be a bug in another part of my rather large program? Or is it really a bug in the BSL? Jean-Noël _____ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users _____ _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users