https://bugs.freedesktop.org/show_bug.cgi?id=40423 --- Comment #21 from Nicholas Miell <nmiell@xxxxxxxxx> 2011-09-30 20:45:37 PDT --- It isn't a bug, it is a perfectly valid and entirely safe optimization. Valgrind supplies its own overrides for the string functions that don't do this optimization specifically to prevent false positives from the C library, but in this case the false positive results from a call to strlen() that gcc has inlined. Does jemalloc (or Firefox's fork of jemalloc) obey the platform ABI requirements for the alignment of the return values of the malloc functions? Because gcc's value range propagation has carried the fact that the pointer was returned by calloc to the point where it has inlined strlen(), and knowing that the pointer has to be word aligned, it has omitted the usual byte-at-a-time strlen() preamble and skipped straight to word-at-a-time loads. jemalloc's INSTALL lists the following option: --disable-tiny Disable tiny (sub-quantum-sized) object support. Technically it is not legal for a malloc implementation to allocate objects with less than quantum alignment (8 or 16 bytes, depending on architecture), but in practice it never causes any problems if, for example, 4-byte allocations are 4-byte-aligned. If, for example, jemalloc decides to stick a 4 byte allocation in the last 4 bytes of a page on a 64-bit plaform (i.e. word size is 8 bytes), and gcc's value range propagation can follow a pointer from a malloc function to an inlined strlen, things will explode violently. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
