similar to: UB in MemoryBufferMMapFile

Chris Lattner <clattner at apple.com> writes: > On Nov 16, 2016, at 9:46 PM, Justin Bogner via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> In MemoryBuffer::init, we have an assert that reads the memory at >> `BufEnd`, which is one past the end of some memory region: >> >> from lib/Support/MemoryBuffer.cpp:45: >>> void

I mad the change, and still have the problem. I investigate more the source code of llvm. First, I change isRawBitcode function to print the content of the parameter like this: original: http://llvm.org/docs/doxygen/html/ReaderWriter_8h_source.html#l00081 inline bool isRawBitcode(const unsigned char *BufPtr, const unsigned char *BufEnd) { // These bytes sort

all of: ---- // cout << "lsr: " << lsr << "\n"; llvm::MemoryBuffer* mbjit = llvm::MemoryBuffer::getMemBufferCopy (sr); ------ string lsr = sr.str(); // cout << "lsr: " << lsr << "\n";

Hello, I having a weird problem while writing a bytecode module to a string, and after read/parse it for unsing on a jit. I write a pass to export function to module, and put this module inside a global variable. I use WriteBitcodeToFile for this. For debuging, after this write, I try to load the exported module with parseBitcodeFile. This two step works. After, while the compiled program is

This segfault occuring only under valgrind, in shell way, and in gdb way i have Invalid bitcode signature simple_scev_dynamic_array: /home/willy/apollo/llvm/include/llvm/Support/ErrorOr.h:258: storage_type *llvm::ErrorOr<llvm::Module *>::getStorage() [T = llvm::Module *]: Assertion `!HasError && "Cannot get value when an error exists!"' failed. Command terminated by

Hello Willy, Here is the dump from one of my bitcode files: 0000000 42 43 c0 de 21 0c 00 00 25 05 00 00 0b 82 20 00 As expected, 0x42 (= B), 0x43 (= C), xc0 and 0xde are in correct order. In your case, the first byte is read as 37 (= 0x25). I wonder why? When you check the bytes yourself, you get expected results. When the same bytes are read from Stream object, you get a different result (maybe

I was writing something using MemoryBuffer, and while looking through its code I came across line 59: assert(BufEnd[0] == 0 && "Buffer is not null terminated!"); I am curious if the MemoryBuffer only supports non-binary, non-null embedded files, or if it supports binary as well. I do not see anything inherently not expecting binary files except for that one line, so I am

On Thu, Sep 24, 2009 at 2:32 PM, Chris Lattner <clattner at apple.com> wrote: > > On Sep 24, 2009, at 1:23 PM, OvermindDL1 wrote: > >> I was writing something using MemoryBuffer, and while looking through >> its code I came across line 59: >> assert(BufEnd[0] == 0 && "Buffer is not null terminated!"); >> I am curious if the MemoryBuffer

Currently a power failure or other hard crash can cause lld leave a temporary file around. The same is true for other llvm tools. As an example, put a breakpoint in Writer.cpp:236 ("writeBuildId()") and restart the run a few times. You will get t.tmp43a735a t.tmp4deeabb t.tmp9bacdd3 t.tmpe4115c4 t.tmpeb01fff The same would happen if there was a fatal error between the

Hi Rafael, Would you mind waiting for Derek to come back from vacation to discuss this? We do use this code and could improve how it's used and tested within LLVM. Derek is the best person to discuss this, he'll be back in mid-January. Thanks, JF On Fri, Dec 19, 2014 at 6:41 AM, Rafael Espíndola < rafael.espindola at gmail.com> wrote: > > > I CC'ed llvmdev to put a

Hi Rafael, We will try out your patch and check to see how it will fit. You also talked about "It might be even possible to drop the requirement for the size to be known: Replace the call to AtEndOfStream by just trying to read more and checking if it failed, but that is a bit more than I wanted to do for this." That is to remove some calls to getSize()? Is there any expectation that

On Thu, Sep 24, 2009 at 4:26 PM, Gordon Henriksen <gordonhenriksen at me.com> wrote: > NUL-termination is an optimization, in particular for clang's parser, > where it's cheaper to check for '\0' to signal EOF than it is to > compare pointers. Its presence doesn't move the end iterator (just > makes it dereference-able) and in no way impacts your ability to

Hello all Im using sftp 1:4.7p1-8ubuntu1.2 in a batchjob Ive noticed that sftp needs a long time for sending a filelist. The timespan increases exponential if many files are on the remoteserver. for example "ls -la *.txt" needs 10 seconds for 2000 files but needs 50 seconds for 4000 files. For 150.000 Files i have to wait 15 minutes for example but the

Okay, I am using libshout to stream to a NullSoft Shoutcast server. I am using libmad and libmp3lame to do re-encoding on the fly. I am streaming to the server (currently) with shout_send_raw(). When I try to use shout_metadata_add(), I get a segfault in strdup(). Anyone have any ideas as to why? Everything else works fine, just not the metadata. Thanks In Advance, Deven --- >8 ----

Mihai, Here's the full backtrace. (gdb) bt full #0 0x40292093 in strlen () from /lib/i686/libc.so.6 No symbol table info available. #1 0x40291dc5 in strdup () from /lib/i686/libc.so.6 No symbol table info available. #2 0x400aed79 in _shout_util_dict_set (dict=0x0, key=0x804b746 "song", val=0x0) at util.c:236 prev = (util_dict *) 0x80555b8 #3 0x400ad61b in

Hola, Para este verano hemos organizado dos cursos de extensión universitaria (sin requisitos previos) en el Departamento de Estadística de la Universidad de Barcelona (Facultad de Biología). Los títulos son: * Gestión de datos, programación y gráficos con R * Estadística aplicada con R Son dos cursos de introducción a R de 20 horas cada uno. El primero orientado a empezar a trabajar con R y

The commit <http://git.xiph.org/?p=flac.git;a=commitdiff;h=e3c8095336249182b6a8871747df3cc99640103a> fixed UB in bitwriter.c. But there are 2 unused functions - FLAC__bitwriter_rice_bits() and FLAC__bitwriter_write_rice_signed() that also have this UB. IMHO it makes sense to fix their code as well. Maybe someone will use them in future. -------------- next part -------------- A non-text

On Feb 11, 2013, at 12:02 PM, David Blaikie <dblaikie at gmail.com> wrote: > Beyond that, though, I've hit one hierarchy in the Static Analyzer > that does this as well: ProgramPoint. On IRC Jordan Rose mentioned > that there's another more pervasive use of this pattern in the Static > Analyzer, the SVal hierarchy. > > So, Ted, how objectionable would it be for me

I believe this assert is wrong since it checks memory outside of the buffer. It shouldn't make assumptions on how callers store the array. Yuri

Hi David, Vedant, It looks like we might have UB somewhere connected with reading coverage mapping serialized in v2 format (with compressed function names). I committed my patch, r266436, using the current format for .covmapping file, and then buildbots complained about it: * http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/11935/steps/check-llvm%20ubsan/logs/stdio *