[devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1450 bytes --]

Здравствуйте !

Разбираясь с тем, почему происходит выпадение в core 32-битной 
версии palemoon, пришёл к выводу, что падение происходит в 
функции malloc, а именно на этом участке кода (файл malloc.c из 
glibc-core):

Вызов из palemoon:
 options = malloc (sizeof (cairo_font_options_t));

Код malloc.c:
стр 3350
  if (in_smallbin_range(nb)) {
    idx = smallbin_index(nb);
    bin = bin_at(av,idx);

    if ( (victim = last(bin)) != bin) {
      if (victim == 0) /* initialization check */
	malloc_consolidate(av);
      else {
	bck = victim->bk;
===> (стр 3359)	if (__builtin_expect (bck->fd != victim, 0))
	  {
	    errstr = "malloc(): smallbin double linked list corrupted";
	    goto errout;
	  }
	set_inuse_bit_at_offset(victim, nb);
	bin->bk = bck;
	bck->fd = bin;

	if (av != &main_arena)
	  victim->size |= NON_MAIN_ARENA;
	check_malloced_chunk(av, victim, nb);
	void *p = chunk2mem(victim);
	if (__builtin_expect (perturb_byte, 0))
	  alloc_perturb (p, bytes);
	return p;
      }
    }

А именно, судя по всему в victim->bk находится 0, и bck->fd 
превращается в null->fd.

Это глюк malloc, или неправильное обращение от palemoon?
Мне всё-же кажется, что самого glibc.

-- 
  А ещё говорят так  (fortune):
 
If men acted after marriage as they do during courtship, there 
would be fewer divorces -- and more bankruptcies. -- Frances 
Rodman 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 1559 bytes --]

On Sat, Jul 25, 2015 at 06:17:28AM +0300, Hihin Ruslan wrote:
> Здравствуйте !
> 
> Разбираясь с тем, почему происходит выпадение в core 32-битной 
> версии palemoon, пришёл к выводу, что падение происходит в 
> функции malloc, а именно на этом участке кода (файл malloc.c из 
> glibc-core):
> 
> Вызов из palemoon:
>  options = malloc (sizeof (cairo_font_options_t));
> 
> Код malloc.c:
> стр 3350
>   if (in_smallbin_range(nb)) {
>     idx = smallbin_index(nb);
>     bin = bin_at(av,idx);
> 
>     if ( (victim = last(bin)) != bin) {
>       if (victim == 0) /* initialization check */
> 	malloc_consolidate(av);
>       else {
> 	bck = victim->bk;
> ===> (стр 3359)	if (__builtin_expect (bck->fd != victim, 0))
> 	  {
> 	    errstr = "malloc(): smallbin double linked list corrupted";
> 	    goto errout;
> 	  }
> 	set_inuse_bit_at_offset(victim, nb);
> 	bin->bk = bck;
> 	bck->fd = bin;
> 
> 	if (av != &main_arena)
> 	  victim->size |= NON_MAIN_ARENA;
> 	check_malloced_chunk(av, victim, nb);
> 	void *p = chunk2mem(victim);
> 	if (__builtin_expect (perturb_byte, 0))
> 	  alloc_perturb (p, bytes);
> 	return p;
>       }
>     }
> 
> А именно, судя по всему в victim->bk находится 0, и bck->fd 
> превращается в null->fd.
> 
> Это глюк malloc, или неправильное обращение от palemoon?
> Мне всё-же кажется, что самого glibc.

Если у вас memory corruption, то glibc -- это последнее место,
которое стоит проверять.

Есть разные средства отладки, проверьте сперва ими.  Начните с valgrind.


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Руслан Хихин]

Вот с их помощью на это место и вышел.


------ Исходное сообщение ------
От: "Dmitry V. Levin" <ldv@altlinux.org>
Отправлено: 25 июля 2015 г. 12:53:37 GMT+03:00
Кому: ALT Devel discussion list <devel@lists.altlinux.org>
Тема: Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

On Sat, Jul 25, 2015 at 06:17:28AM +0300, Hihin Ruslan wrote:
> Здравствуйте !
> 
> Разбираясь с тем, почему происходит выпадение в core 32-битной 
> версии palemoon, пришёл к выводу, что падение происходит в 
> функции malloc, а именно на этом участке кода (файл malloc.c из 
> glibc-core):
> 
> Вызов из palemoon:
>  options = malloc (sizeof (cairo_font_options_t));
> 
> Код malloc.c:
> стр 3350
>   if (in_smallbin_range(nb)) {
>     idx = smallbin_index(nb);
>     bin = bin_at(av,idx);
> 
>     if ( (victim = last(bin)) != bin) {
>       if (victim == 0) /* initialization check */
> 	malloc_consolidate(av);
>       else {
> 	bck = victim->bk;
> ===> (стр 3359)	if (__builtin_expect (bck->fd != victim, 0))
> 	  {
> 	    errstr = "malloc(): smallbin double linked list corrupted";
> 	    goto errout;
> 	  }
> 	set_inuse_bit_at_offset(victim, nb);
> 	bin->bk = bck;
> 	bck->fd = bin;
> 
> 	if (av != &main_arena)
> 	  victim->size |= NON_MAIN_ARENA;
> 	check_malloced_chunk(av, victim, nb);
> 	void *p = chunk2mem(victim);
> 	if (__builtin_expect (perturb_byte, 0))
> 	  alloc_perturb (p, bytes);
> 	return p;
>       }
>     }
> 
> А именно, судя по всему в victim->bk находится 0, и bck->fd 
> превращается в null->fd.
> 
> Это глюк malloc, или неправильное обращение от palemoon?
> Мне всё-же кажется, что самого glibc.

Если у вас memory corruption, то glibc -- это последнее место,
которое стоит проверять.

Есть разные средства отладки, проверьте сперва ими.  Начните с valgrind.



-- 
Простите за краткость, создано в K-9 Mail.

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 297 bytes --]

On Sat, Jul 25, 2015 at 12:57:01PM +0300, Руслан Хихин wrote:
> Вот с их помощью на это место и вышел.

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 1143 bytes --]

Здравствуйте Dmitry V. Levin
  В сообщении от 25 июля 2015 Dmitry V. Levin написал(a):
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?

Извините - с телефона отвечал.  valgrind
 - это, конечно, хорошо, но пугают цифры:

==19357== LEAK SUMMARY:
==19357==    definitely lost: 44,131 bytes in 828 blocks
==19357==    indirectly lost: 18,610 bytes in 1,133 blocks
==19357==      possibly lost: 4,804,441 bytes in 17,195 blocks
==19357==    still reachable: 26,510,770 bytes in 189,137 blocks
==19357==         suppressed: 0 bytes in 0 blocks
==19357== Reachable blocks (those to which a pointer was found) 
are not shown.
==19357== To see them, rerun 
with: --leak-check=full --show-leak-kinds=all
==19357== 
==19357== For counts of detected and suppressed errors, rerun 
with: -v
==19357== Use --track-origins=yes to see where uninitialised 
values come from
==19357== ERROR SUMMARY: 11515 errors from 3757 contexts 
(suppressed: 2 from 1)


-- 
  А ещё говорят так  (fortune):
 
Склероз вылечить нельзя, зато о нем можно забыть 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 2280 bytes --]

Здравствуйте Dmitry V. Levin
  В сообщении от 25 июля 2015 Dmitry V. Levin написал(a):
> On Sat, Jul 25, 2015 at 12:57:01PM +0300, Руслан Хихин wrote:
> > Вот с их помощью на это место и вышел.
>
> A: Because it messes up the order in which people normally
> read text. Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?

Вот как мне такое место расшифровать?

==19389== 3 bytes in 1 blocks are still reachable in loss record 
1 of 356
==19389==    at 0x40294DA: malloc (vg_replace_malloc.c:296)
==19389==    by 0x4271B40: strdup (strdup.c:42)
==19389==    by 0x47BE19C: PR_NewLogModule (prlog.c:356)
==19389==    by 0x47C9A0B: _PR_InitStuff (prinit.c:155)
==19389==    by 0x47D2E04: PR_NewLock (ptsynch.c:140)
==19389==    by 0x8AF30A3: InstallSignalHandlersMutex 
(AsmJSSignalHandlers.cpp:162)
==19389==    by 0x8AF30A3: 
__static_initialization_and_destruction_0 
(AsmJSSignalHandlers.cpp:177)
==19389==    by 0x8AF30A3: _GLOBAL__sub_I_AsmJSSignalHandlers.cpp 
(AsmJSSignalHandlers.cpp:998)
==19389==    by 0x400EFDD: call_init.part.0 (dl-init.c:82)
==19389==    by 0x400F0C9: call_init (dl-init.c:34)
==19389==    by 0x400F0C9: _dl_init (dl-init.c:130)
==19389==    by 0x401310C: dl_open_worker (dl-open.c:566)
==19389==    by 0x400EE4D: _dl_catch_error (dl-error.c:177)
==19389== +   by 0x4012943: _dl_open (dl-open.c:656)
==19389==    by 0x4046CCD: dlopen_doit (dlopen.c:66)
==19389==.

У меня такого файла в исходниках - vg_replace_malloc вообще нет, 
а strdup(42) - это неправильное присвоение:

char *s
....
s="";
....

c тем, что-бы дальше передать его в какой-то ....strlen

Вот дословно этот кусок:

PR_IMPLEMENT(char *)
PL_strndup(const char *s, PRUint32 max)
{
    char *rv;
    size_t l;

    if( (const char *)0 == s )
        s = "";

    l = PL_strnlen(s, max);

    rv = (char *)malloc(l+1);
    if( (char *)0 == rv ) return rv;

    (void)memcpy(rv, s, l);
    rv[l] = '\0';

    return rv;
}






-- 
  А ещё говорят так  (fortune):
 
<Iambe> you are not a nutcase <Knghtbrd> You obviously don't know 
me well enough yet. => 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Dmitry V. Levin]

[-- Attachment #1: Type: text/plain, Size: 674 bytes --]

On Sat, Jul 25, 2015 at 06:39:28PM +0300, Hihin Ruslan wrote:
> Здравствуйте Dmitry V. Levin
>   В сообщении от 25 июля 2015 Dmitry V. Levin написал(a):
> > On Sat, Jul 25, 2015 at 12:57:01PM +0300, Руслан Хихин wrote:
> > > Вот с их помощью на это место и вышел.
> >
> > A: Because it messes up the order in which people normally
> > read text. Q: Why is top-posting such a bad thing?
> > A: Top-posting.
> > Q: What is the most annoying thing in e-mail?
> 
> Вот как мне такое место расшифровать?
> 
> ==19389== 3 bytes in 1 blocks are still reachable in loss record 
> 1 of 356

Это про утечки памяти, ищите лучше "Invalid write of size ".


-- 
ldv

[-- Attachment #2: Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Hihin Ruslan]

[-- Attachment #1: Type: text/plain, Size: 2057 bytes --]

Здравствуйте Dmitry V. Levin
  В сообщении от 25 июля 2015 Dmitry V. Levin написал(a):
> On Sat, Jul 25, 2015 at 06:39:28PM +0300, Hihin Ruslan wrote:
> > Здравствуйте Dmitry V. Levin
> >
> >   В сообщении от 25 июля 2015 Dmitry V. Levin написал(a):
> > > On Sat, Jul 25, 2015 at 12:57:01PM +0300, Руслан Хихин 
wrote:
> > > > Вот с их помощью на это место и вышел.
> > >
> > > A: Because it messes up the order in which people normally
> > > read text. Q: Why is top-posting such a bad thing?
> > > A: Top-posting.
> > > Q: What is the most annoying thing in e-mail?
> >
> > Вот как мне такое место расшифровать?
> >
> > ==19389== 3 bytes in 1 blocks are still reachable in loss
> > record 1 of 356
>
> Это про утечки памяти, ищите лучше "Invalid write of size ".

Похоже, проблема с указателем nullptr, указывает на строчки типа 

    mHashtable =  nullptr;

он хитро определен (файл  mfbt/NullPtr.h ):



#define mozilla_NullPtr_h_

#include "mozilla/Compiler.h"

#if defined(__clang__)
#  ifndef __has_extension
#    define __has_extension __has_feature
#  endif
#  if __has_extension(cxx_nullptr)
#    define MOZ_HAVE_CXX11_NULLPTR
#  endif
#elif defined(__GNUC__)
#  if defined(__GXX_EXPERIMENTAL_CXX0X__) || __cplusplus >= 
201103L
#    if MOZ_GCC_VERSION_AT_LEAST(4, 6, 0)
#      define MOZ_HAVE_CXX11_NULLPTR
#    endif
#  endif
#elif _MSC_VER >= 1600
# define MOZ_HAVE_CXX11_NULLPTR
#endif

/**
 * Use C++11 nullptr if available; otherwise use __null for gcc, 
or a 0 literal
 * with the correct size to match the size of a pointer on a 
given platform.
 */

#ifndef MOZ_HAVE_CXX11_NULLPTR
#  if defined(__GNUC__)
#    define nullptr __null
#  elif defined(_WIN64)
#    define nullptr 0LL
#  else
#    define nullptr 0L
#  endif
#endif

#endif  /* mozilla_NullPtr_h_ */



-- 
  А ещё говорят так  (fortune):
 
IN MY OPINION anyone interested in improving himself should not 
rule out becoming pure energy. -- Jack Handley, The New Mexican, 
1988. 
________________________________________________________________________
С уважением Хихин Руслан

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [devel] Ошибка выделения памяти в malloc в 32-х битной архитектуре

[Хихин Руслан]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Здравствуйте !
On Saturday 25 July 2015 18:51:02 Dmitry V. Levin написал(а):

> Это про утечки памяти, ищите лучше "Invalid write of size ".

Спасибо, Дима, в общем проблема была в неправильном размере указателя, 
решилась (стучу по деревяшке, т.к. прошедшее через Сизифную сборочницу ещё не 
тестировалояь) добавлением опции -march=i586. 
Странно, что версия для p7/t7 работала без проблем и без этой опции. Я думаю, 
это наверное, было связано с другой архитектурой процессора на сборочницах. 
Хотя могут быть варианты.

-- 
C уважением, Хихин Руслан.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 198 bytes --]