LINUX.ORG.RU
решено Форум — Development  

g++ баг?


0

1

Доброго времени суток. Недавно пробовал написать простой «морской бой» на g++ и вот что получил: Компилятор (все по дефолту) некорректно обрабатывает циклы и не всегда правильно работает с массивами. Я и раньше замечал подобное, но сейчас у меня появилась реальная проблема.

	int Field1[9][9];

	for (int x=0;x<10;x++)
	{
		for (int y=0;y<10;y++)
		{
		Field1[x][y]=0; cout << x << y;}
	}

Dropbox

Программа элементарная. Однако: 1. [6][9],[7][9],[8][9],[9][9] элементы массива заполняются элементами, взятыми «с потолка»; 2.С чего-то вдруг компилятор превратил for в бесконечный цикл, так что программа вообще не завершается сама.

Причем на Dev-C++ под виндой все прекрасно присваивается и выводится( правда, некорректное завершение работы происходит).Обидно, знаете. Надеюсь на вашу помощь.

Правка №1:

Господа, обратите внимание! Массивы начинаются с НУЛЯ, не с единицы. Там 10 элементов. А в цикле если x/y < 10 (10 не меньше 10), то все работает нормально. То есть, значения x и y меняются с 0 до 9. Пожалуйста, проверяйте прогу, прежде чем комментировать. У меня есть повод говорить о баге компилятора, поскольку под окнами все отлично работает.



Последнее исправление: ms-dos32 (всего исправлений: 3)
← Мой проект глазами компилятора
[C++11] Инициализация std::array →
  1 2 →

о размерах массива 

int Field1[10][10];
уже сказали?

Chaser_Andrey ★★★★★
()
Ответ на: комментарий от geekless

Боюсь, что это может случиться уже совершенно в другом месте программы.

delete83 ★★
()
Ответ на: комментарий от hizel

Тем не менее, под виндой при компиляции в VS я получаю access violation и сразу знаю, где я не прав, а тут все втихаря. Понятно, что сам gcc не виноват. Виноват рантайм, который вовремя не забил тревогу. Вот от этого и печально. От ошибок таких никто не застрахован.

delete83 ★★
()
Ответ на: комментарий от delete83

не при компиляции, конечно, access violation, а при выполнении скомпилированной программы.

delete83 ★★
()
Ответ на: комментарий от pacify

[denis@delete[ArchLinux] Downloads]$ valgrind -v ./test
==1780== Memcheck, a memory error detector
==1780== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==1780== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info
==1780== Command: ./test
==1780==
--1780-- Valgrind options:
--1780-- -v
--1780-- Contents of /proc/version:
--1780-- Linux version 3.0-ARCH (tobias@T-POWA-LX) (gcc version 4.6.1 20110819 (prerelease) (GCC) ) #1 SMP PREEMPT Wed Oct 19 10:27:51 CEST 2011
--1780-- Arch and hwcaps: AMD64, amd64-sse3
--1780-- Page sizes: currently 4096, max supported 4096
--1780-- Valgrind library directory: /usr/lib/valgrind
--1780-- Reading syms from /home/denis/Downloads/test (0x400000)
--1780-- Reading syms from /lib/ld-2.14.so (0x4000000)
--1780-- Reading syms from /usr/lib/valgrind/memcheck-amd64-linux (0x38000000)
--1780-- object doesn't have a symbol table
--1780-- object doesn't have a dynamic symbol table
--1780-- Reading suppressions file: /usr/lib/valgrind/default.supp
--1780-- REDIR: 0x4016a60 (strlen) redirected to 0x3805f7b7 (???)
--1780-- Reading syms from /usr/lib/valgrind/vgpreload_core-amd64-linux.so (0x4a21000)
--1780-- object doesn't have a symbol table
--1780-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so (0x4c22000)
--1780-- object doesn't have a symbol table
==1780== WARNING: new redirection conflicts with existing — ignoring it
--1780-- new: 0x04016a60 (strlen ) R-> 0x04c26de0 strlen
--1780-- REDIR: 0x40167a0 (index) redirected to 0x4c26a00 (index)
--1780-- REDIR: 0x4016950 (strcmp) redirected to 0x4c279e0 (strcmp)
--1780-- Reading syms from /lib/libc-2.14.so (0x4e2c000)
--1780-- object doesn't have a symbol table
--1780-- REDIR: 0x4ea9e90 (rindex) redirected to 0x4c26790 (rindex)
^C==1780==
==1780== Process terminating with default action of signal 2 (SIGINT)
==1780== at 0x4005AF: main (in /home/denis/Downloads/test)
--1780-- REDIR: 0x4ea30a0 (free) redirected to 0x4c25500 (free)
==1780==
==1780== HEAP SUMMARY:
==1780== in use at exit: 0 bytes in 0 blocks
==1780== total heap usage: 0 allocs, 0 frees, 0 bytes allocated
==1780==
==1780== All heap blocks were freed — no leaks are possible
==1780==
==1780== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)
--1780--
--1780-- used_suppression: 7 dl-hack3-cond-1
==1780==
==1780== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 7)

[denis@delete[ArchLinux] Downloads]$


Надо перекомпилить с отладочной информацией?

delete83 ★★
()
Ответ на: комментарий от pacify

Бесполезно. Я не буду еще одну простыню постить, но там то же самое в конце. Прерываю работу программы по ^C и такой же вывод valgrind. Он же вроде предназначен для ловли ошибок выделения памяти в куче?

delete83 ★★
()
Ответ на: комментарий от delete83

Странно.

gcc version 4.4.5

$ g++ t1.cc -fstack-check -o t1 && ./t1
Segmentation fault


$ /usr/bin/i586-mingw32msvc-g++ t1.cc -o t1.exe -fstack-check && wine ./t1.exe
[
Segmentation fault

anonymous
()
Ответ на: комментарий от anonymous

Соответственно, без -fstack-check уходит в бесконечный цикл и там, и там.

anonymous
()
Ответ на: комментарий от delete83

Не, линукс не падает в сегфолт, если писать и читать не по адресу. По-крайней мере у меня не падал, когда я дебажил адресную арифметику. Писал и читал не в 0x00000000 конечно же :)

tensai_cirno ★★★★★
()
Ответ на: комментарий от anonymous

$ /usr/bin/i586-mingw32msvc-g++ --version
i586-mingw32msvc-g++ (GCC) 4.4.4

anonymous
()
Ответ на: комментарий от hizel

Моя это ошибка. Не надо было фигней голову забивать, и все было бы нормально. Что интересно, в режиме отладки у меня ошибка сегментации выходила только при выходе из main.

ms-dos32
() автор топика
Ответ на: комментарий от delete83

А вот с gcc взлетело только с включенной опцией -std=gnu99 и выдало вот такой вот результат. Даже лучше, чем с g++. 

[denis@delete[ArchLinux] Downloads]$ gcc sea.c -g -fstack-protector-all -std=gnu99 -o test && ./test
    A B C D E F G H I J
0:  0 0 0 0 0 0 0 0 0 0
1:  0 0 0 0 0 0 0 0 0 0
2:  0 0 0 0 0 0 0 0 0 0
3:  0 0 0 0 0 0 0 0 0 0
4:  0 0 0 0 0 0 0 0 0 0
5:  0 0 0 0 0 0 0 0 0 0
6:  0 0 0 0 0 0 0 0 0 0
7:  0 0 0 0 0 0 0 0 0 0
8:  0 0 0 0 0 0 0 0 0 0
9:  0 0 0 0 0 0 0 0 0 0
*** stack smashing detected ***: ./test terminated
======= Backtrace: =========
/lib/libc.so.6(__fortify_fail+0x37)[0x7f71ddb63037]
/lib/libc.so.6(__fortify_fail+0x0)[0x7f71ddb63000]
./test[0x400741]
======= Memory map: ========
00400000-00401000 r-xp 00000000 00:10 571829                             /home/denis/Downloads/test
00600000-00601000 rw-p 00000000 00:10 571829                             /home/denis/Downloads/test
017b7000-017d8000 rw-p 00000000 00:00 0                                  [heap]
7f71dd864000-7f71dd879000 r-xp 00000000 00:10 311526                     /usr/lib/libgcc_s.so.1
7f71dd879000-7f71dda79000 ---p 00015000 00:10 311526                     /usr/lib/libgcc_s.so.1
7f71dda79000-7f71dda7a000 rw-p 00015000 00:10 311526                     /usr/lib/libgcc_s.so.1
7f71dda7a000-7f71ddbd1000 r-xp 00000000 00:10 266002                     /lib/libc-2.14.so
7f71ddbd1000-7f71dddd0000 ---p 00157000 00:10 266002                     /lib/libc-2.14.so
7f71dddd0000-7f71dddd4000 r--p 00156000 00:10 266002                     /lib/libc-2.14.so
7f71dddd4000-7f71dddd5000 rw-p 0015a000 00:10 266002                     /lib/libc-2.14.so
7f71dddd5000-7f71dddda000 rw-p 00000000 00:00 0 
7f71dddda000-7f71dddf9000 r-xp 00000000 00:10 266004                     /lib/ld-2.14.so
7f71ddfd2000-7f71ddfd5000 rw-p 00000000 00:00 0 
7f71ddff5000-7f71ddff8000 rw-p 00000000 00:00 0 
7f71ddff8000-7f71ddff9000 r--p 0001e000 00:10 266004                     /lib/ld-2.14.so
7f71ddff9000-7f71ddffa000 rw-p 0001f000 00:10 266004                     /lib/ld-2.14.so
7f71ddffa000-7f71ddffb000 rw-p 00000000 00:00 0 
7fff968b3000-7fff968d4000 rw-p 00000000 00:00 0                          [stack]
7fff968ee000-7fff968ef000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0                  [vsyscall]
Аварийный останов
[denis@delete[ArchLinux] Downloads]$

delete83 ★★
()
Ответ на: комментарий от ms-dos32

Вообще-то, если ты не заметил, я компилил исходник как g++, так и gcc, а значит немного над ним поиздевался. И конечно же первым делом исправил циферки, как в первом посте темы.

delete83 ★★
()
Ответ на: комментарий от backbone

Простите, вы хоть комменты читали? Я уже несколько часов как разобрался с этой проблемой, что же касается Кернигана, то поговаривают, будто его труды устаревают. Хотя, возможно это лишь слухи.

ms-dos32
() автор топика
Ответ на: комментарий от ms-dos32

Ссори, эмоции, не увидел тега [solved]. :)
Сам и не такое писал, особенно когда долго не отдыхать.
Ну эта книга вряд ли устареет.

backbone ★★★★★
()
Ответ на: комментарий от ms-dos32

> Что интересно, в режиме отладки у меня ошибка сегментации выходила только при выходе из main.

Все просто. Затерли адрес возврата из функции (он тоже лежит на стеке, как и массив). Инструкция ret попыталась передать управление на нулевой адрес — вот и сегфолт.

Relan ★★★★★
()
Ответ на: комментарий от backbone

> В хорошем качестве вот 3-е издание Керниган и Ритчи.

4.2

Это перевод второго издания. Никакого «3-е издания» K&R нет, не было и уже не будет.

LamerOk ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
  1 2 →
← Мой проект глазами компилятора
Development
[C++11] Инициализация std::array →