Not null terminated file

Hello,
The last days I have a problem with a tool of me. I think its more related to ClearCase, but I hope that someone had a similar problem.

The tool runs over a project in my company and check for our styleguide.
The code of the project is managed by ClearCase.

The assertion “Buffer is not null terminated!” in MemoryBuffer::init fails.
After some investigations I figure out that it is allways the same file from include path. The file by its own is ok and after a reboot it is another file.

When I copy everything on a local disk it works fine.

I know it sounds more like a problem with ClearCase, but our support is still on it with no clue.
Did someone knows this error and can help me?

Kind Regards,
Robert

Von Samsung Mobile gesendet

Hello,
The last days I have a problem with a tool of me. I think its more related to ClearCase, but I hope that someone had a similar problem.

The tool runs over a project in my company and check for our styleguide.
The code of the project is managed by ClearCase.

The assertion "Buffer is not null terminated!" in MemoryBuffer::init fails.
After some investigations I figure out that it is allways the same file from include path. The file by its own is ok and after a reboot it is another file.

This sounds like a bug in clang. Can you file a bug report and specify which version you're using (release and/or SVN revision), OS and platform? Also mention the exact size (in bytes) of the file in question, and a stack trace if available. Let us know the PR number here.

Thanks

Alp.

Hello,
The last days I have a problem with a tool of me. I think its more related
to ClearCase, but I hope that someone had a similar problem.

The tool runs over a project in my company and check for our styleguide.
The code of the project is managed by ClearCase.

The assertion "Buffer is not null terminated!" in MemoryBuffer::init
fails.
After some investigations I figure out that it is allways the same file
from include path. The file by its own is ok and after a reboot it is
another file.

When I copy everything on a local disk it works fine.

So originally there is a different file system in between? I have no
experience with ClearCase...

Hello,
thanks for the replies.

Sorry that I forgot the OS.
I use Win7 SP1 64bit Enterprise.
CPU is a i5-3470 and 8GB RAM.
I compiled clang for mingw64-seh.
The cmake command I use is: cmake -G “MSYS Makefiles” -DCMAKE_INSTALL_PREFIX=“/d/Datenkrake/Mingw” -DCMAKE_BUILD_TYPE=Release -DLLVM_TARGETS_TO_BUILD=“X86” “$@” …

The files where the error occure got the size from nearly 700b to 36kb.

At least I know that it is a network filesystem.
The Explorer shows MVFS for this drive.

I tried several versions of clang. The current I use is from the SVN of 20.May.14.
All versions I used was 3.5.
I receive the error with all versions.

I cannot send an up-to-date stacktrace of this error because when I try to compile the libraries with debug-symbols my program crashes. So I just can send an older Trace that I create for our Support. I include all files mentioned in the trace for line references.
The stacktrace can be found in stacktrace.txt.
I add them to the Attechment. I hope that helps a bit.

Kind Regards,
Robert

stacktrace.7z (137 KB)

At least I know that it is a network filesystem.
The Explorer shows MVFS for this drive.

OK, this might be a bug in their implementation of CreateFileMappingW.
I assume it is required to zero fill the last bytes, just like mmap.
I am not sure if it is easy to work around this. Is there a cheap
system call to find what is the FS type responsible far a handle?

Cheers,
Rafael

Actually, something along the lines of llvm.org/pr19868 is probably a
better way to handle this.

Cheers,
Rafael

This sounds good to me. Especially for the check of the last byte.
Should I report my issue there too?

Best,
Robert

I think the bug covers it, no?

If you have more information you want to add to the bug, pleas do.

Cheers,
Rafael