On Wed, Jul 13, 2011 at 11:22:26AM +0400, Dmitry V. Levin wrote:
> On Wed, Jul 13, 2011 at 10:20:25AM +0700, REAL wrote:
> > На x86_64 с matplotlib при сборке в gear 
> > воспроизводится в ~90% случаев, но в hsh-shell 
> > так и не удалось.
> 
> Тогда имеет смысл снять ограничения на коркообразование, получить корку и
> посмотреть на нее.

Core was generated by `/usr/bin/python2.6 setup.py build --debug'.
Program terminated with signal 11, Segmentation fault.
#0  alloc_mmap (address=0x0) at memory.c:361
361		  *(long *)start = (long)start + PAGESIZE;
(gdb) bt
#0  alloc_mmap (address=0x0) at memory.c:361
#1  0xf66e1104 in blas_memory_alloc (procpos=2) at memory.c:915
#2  0xf66e185e in blas_thread_server (arg=0x0) at blas_server.c:242
#3  0xf74eb940 in start_thread (arg=0xf5c99b70) at pthread_create.c:297
#4  0xf75ce8ae in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130
(gdb) l
356		
357		start   = (BLASULONG)map_address;
358		current = (SCALING - 1) * BUFFER_SIZE;
359		
360		while(current > 0) {
361		  *(long *)start = (long)start + PAGESIZE;
362		  start += PAGESIZE;
363		  current -= PAGESIZE;
364		}
365		
(gdb) p map_address
$1 = (void *) 0xecdf2000
(gdb) p/x start
$3 = 0xecdf2000
(gdb) p *(long*)map_address
Cannot access memory at address 0xecdf2000

Картина примерно следующая: тред при старте делает
map_address = mmap(NULL, 0x2000000, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0);
mbind(map_address, 0x20000000, MPOL_PREFERRED, NULL, 0, 0);
сразу после этого пытается записать long по адресу map_address, и
получает SIGSEGV с кодом ошибки 6 (user-mode write access).

Наиболее вероятно, что за время, прошедшее между окончанием mmap(2) и
началом записи, другой тред сделал munmap(2) этой части адресного
пространства.

Подозреваю, хотя и не проверял, что спорадические SIGSEGVы начали
происходить после следующего изменения в gotoblas2:
* Sat Apr 09 2011 Eugeny A. Rostovtsev (REAL) <real at altlinux> 1.13-alt5
- Use pthread instead of OpenMP (inspired by mike@)


-- 
ldv