search for: foreignst

...e both opening "temp.GNU.a"; perhaps the names were truncated in the strace. Anyway, you're right, this isn't the problem if the file names are different. > The > very last open to the "archPath" file is at line 429, where it truncates > it even though the foreignST pointer refers to data mmaped in that file. Yes, the foreignST points to a non-LLVM symbol table which must be retained for compatibility with other AR implementations. Unfortunately, it is being held from a file that is about to be mmap'd. > Is this data supposed to be copied out of th...

...ables are pointing to different files, and the creation of TmpArchive works just fine. The strace including the parts that reference the temporary file is appended to the end of the email. The very last open to the "archPath" file is at line 429, where it truncates it even though the foreignST pointer refers to data mmaped in that file. Is this data supposed to be copied out of the original file, or is another temporary supposed to be created and then the original could be replaced using a file move operation instead? I'll try this on my Debian unstable system tomorrow. If ranlib...

...0 "..., 106) = 106 _llseek(17, 0, [114], SEEK_CUR) = 0 Note that in the "working" case, the C++ library decides to flush the magic number to the file immediately. This causes the first page in the MMAPed file to be allocated (with zeros). Hence, when we go to read the foreignST pointer, it doesn't crash, but it has silently corrupted the data. The foreignST pointer looks like this when it is first read from the file: (gdb) x/46bx foreignST->getData() 0xf6ffe044: 0x00 0x00 0x00 0x02 0x00 0x00 0x07 0x4e 0xf6ffe04c: 0x00 0x00 0x0...

...rst > but llvm-ar > // can deal with it being after a foreign symbol table. This > ensures > // compatibility with other ar(1) implementations as well as > allowing the > // archive to store both native .o and LLVM .bc files, both > indexed. > if (foreignST) { > writeMember(*foreignST, FinalFile, false, false, false); > } So I tracked back the foreignST pointer, and when it is set the "data" pointer is *not* 46 null bytes. It is valid data mmap-ed from the archive file. But when it gets to the call to writeMember, that...

...t; // can deal with it being after a foreign symbol table. This >> ensures >> // compatibility with other ar(1) implementations as well as >> allowing the >> // archive to store both native .o and LLVM .bc files, both >> indexed. >> if (foreignST) { >> writeMember(*foreignST, FinalFile, false, false, false); >> } > > > So I tracked back the foreignST pointer, and when it is set the "data" > pointer is *not* 46 null bytes. It is valid data mmap-ed from the > archive file. But when it get...

...all the members, printing out the first byte of each one. Then it truncates the file and repeats that experiment. It also causes a Bus Error. Essentially, this is what happens in ArchiveWriter.cpp:429. This bug will be triggered by any archive that has a native symbol table, since that member (foreignST) references data that was mmaped from the original file. All the other members are copied from the temporary archive, so they are not a problem. Evan Jones -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: mmaptest.c URL: <http://lists.llv...

...s: 1. Before replacing the original archive file, it invalidates all the members of the current Archive instance. This required me to refactor the destructor code into a separate function. This should make this code work on Windows. 2. I fixed a memory leak in the Archive destructor. The "foreignST" member was never deleted. 3. There are now two temporary files created if we need to build the symbol table, and they are moved over top of the original archive once the process is complete. Let me know if there are any comments. The part where the second temporary file is kind of gross...

On Nov 23, 2005, at 8:16, Evan Jones wrote: > (4) Write the foreignST into the TmpArchive file. Is there any reason > that this isn't possible? Then the final archive would be created in a > single pass, and it could just be moved into place. Ah. I see: It needs to be written in order to compute the offsets. However, it would be possible to use a string...

Evan Jones wrote: > On Nov 23, 2005, at 12:08, Reid Spencer wrote: > >>> However, it would be possible to use a stringstream for this. >> >> Aggg! No! Those perform horribly with anything more than a small >> amount of data. Some Archive files can be huge (e.g. not fit in memory). > > > An archive can be too big to fit in memory? That would be a BIG

...the first byte > of each one. Then it truncates the file and repeats that experiment. It > also causes a Bus Error. > > Essentially, this is what happens in ArchiveWriter.cpp:429. This bug > will be triggered by any archive that has a native symbol table, since > that member (foreignST) references data that was mmaped from the > original file. All the other members are copied from the temporary > archive, so they are not a problem. The file gets corrupted because it is overwriting itself. The strace showed that it opened the same file for reading and writing with 2 file...

Evan Jones wrote: > On Nov 23, 2005, at 8:16, Evan Jones wrote: > >> (4) Write the foreignST into the TmpArchive file. Is there any reason >> that this isn't possible? Then the final archive would be created in a >> single pass, and it could just be moved into place. > > > Ah. I see: It needs to be written in order to compute the offsets. Exactly. > Howev...