On 04/07/2018 06:58 AM, Levente Polyak wrote:
> On April 7, 2018 6:18:39 AM GMT+02:00, "David C. Rankin"
> wrote:
>> On 04/01/2018 07:43 PM, David C. Rankin wrote:
>>>
>>>
>>> I was looking for confirmation of the bug and whether the devs want
>> it
>>> filed here to track or to not waste time fi
On April 7, 2018 6:18:39 AM GMT+02:00, "David C. Rankin"
wrote:
>On 04/01/2018 07:43 PM, David C. Rankin wrote:
>>
>>
>> I was looking for confirmation of the bug and whether the devs want
>it
>> filed here to track or to not waste time filing with Arch and just
>file
>> upstream?
>>
>
>I susp
On 04/01/2018 07:43 PM, David C. Rankin wrote:
>
> Now allocating for 1 integer reports 2 allocations and 1,028 bytes
> instead of 1 allocation and 4 bytes as it did a couple of days ago, e.g.:
>
> #include
> #include
>
> int main (void) {
>
> int *a = malloc (sizeof *a);
> *a = 5;
>
On 3/31/2018 8:56 PM, Oleksii Vilchanskyi wrote:
> So, that's glibc which allocates additional memory for `printf()`, and
> there's nothing wrong with valgrind. Quite the contrary - valgrind can
> be a very sharp Swiss knife.
>
Yes, yes, thanks, I know where the memory is being allocated. This is
On 1.4.2018 00:05, David C. Rankin wrote:
> Devs,
>
> valgrind is reporting more memory allocated than actual. This occurred a
> couple of months back as well, was resolved, and is now apparently back again?
> I don't know if this is a regression, but for each allocation, an additional
> allocat
Devs,
valgrind is reporting more memory allocated than actual. This occurred a
couple of months back as well, was resolved, and is now apparently back again?
I don't know if this is a regression, but for each allocation, an additional
allocation is reported and up to 2^10 additional bytes are re
6 matches
Mail list logo
