(решено)Случайный фактор при формировании стека процесса (просто засада какая-то)

[korisk]

Код:

Код:

#include <stdio.h> int main(int argc, char *argv[], char *env[]){ char b = 1; register int c=0; register char *a = &b; while(1){ *a++ = 1; printf("%x %x\n",(int)a,c++); } return 0; }

Вылетает все время после разного числа итераций.
Размер параметров и массива переменных окружения каждый раз одинаков. Собираю статически. Но в сегменте стека область от &env до argv[argc] разное от запуска к запуску!!! Почему? Что я пропустил? Как пишут книжки, там должны располагаться данные для загрузчика, но почему разная длина?

Может кто подкинет идейку?

[GMar]

код однако пугающий. Уберите операторы типа i++, замените обычным присваиванием, не разберешь что вы там с чем творите
_____________________________________________________
Все, понял, откомпилируйте следующий код и поймете в чем у вас проблема:

Код: Выделить всё

#include <stdio.h>
int main(int argc, char *argv[], char *env[]){
  char b = 1;
  register int c=0;
  register char *a = &b;
  while(1){
    *a++ = 1;
    printf("%x %x\t%i\n",(int)a,c++,a[-1]);
  }
  return 0;
}

[korisk]

код однако пугающий. Уберите операторы типа i++, замените обычным присваиванием, не разберешь что вы там с чем творите

наверное я не ясно описал проблему (

обявляется одна локальная переменная, размещаемая в памяти(стеке)
и две, хранящихся в регистре.
одна из этих двух указатель, который инициализируется адресом локальной.
вторая из двух - счетчик итераций. Они размещаются в регистре, чтобы не затерлись(что обязательно бы произошло, хранись они в стеке)
Далее в цикле указатель инкрементируется до тех пор, пока запись в следующую ячейку не вызовет сегфолт.
Вопрос:
1. почему от запуска к запуску число итераций разное?
2. в другой форм: почему от запуска к запуску стек заполнятеся разными объемами данных.

PS к слову, в венде число итераций между запусками не меняется.

В чем у меня проблема я не понял,. Да, я полностью затираю стек, но если поменять запись на чтение ситуация не изменится

[GMar]

прояснилось...

тут надо копать идеологию gcc и проч...
А проще - задумайтесь, оно вам очень надо? с чем-то это конечно связано, но явно не с какой-то ошибкой в вашем коде
____________________________________________
а стиль кода все-равно пугает, всякие указатели и инкременты - не всегда хорошо (чуть курсовую не запорол из-за них, программа стало виснуть, тупить и т.д.). Вы бы писали больше да разборчивей. это ведь не последняя в вашей жизни программа, будут больше и сложней со временем...
____________________________________________
обратите внимание на содержимое моего варианта кода, строки в начале и в конце похожи по содержимому

[korisk]

тут надо копать идеологию gcc и проч...

Вот.. Поэтому я и спросил на этом форуме, а не на форуме стилистов или java програмистов, которые указателями не пользуются.
Вот.. Поэтому я и спросил на этом форуме, в надежде, что найдется человек, который с подобным сталкивался.
Причина описаного поведениял linux програм, интересна сама по себе, по моему.
Удач.

[drBatty]

Вот.. Поэтому я и спросил на этом форуме, в надежде, что найдется человек, который с подобным сталкивался.
Причина описаного поведениял linux програм, интересна сама по себе, по моему.
Удач.

жуть...
я не понял ваш код. компилятор - тоже.
что вы собственно хотите добиться? "неопределенного поведения"? ну вы его добились

[drBatty]

Они размещаются в регистре, чтобы не затерлись

они НЕ размещаются в регистре. это только пожелание.

1. почему от запуска к запуску число итераций разное?

char b = 1;

это - ошибка. переменной типа char НЕЛЬЗЯ присваивать целое число. это - символ. в данном случае это нестрашно, вы наступили на грабли, но они сломаны...

register int c=0;

ну компилятор и так засунет в регистр c, если надо.
в данном случае - не надо, хотя посмотрите... может и надо...

register char *a = &b;

тут вы приготовили отличные грабли...

*a++ = 1;

а вот тут вы на них наступили.
всё.
дальше можно и не смотреть...
эта "программа" будет работать неизвестно как.

[NickLion]

char b = 1;

это - ошибка. переменной типа char НЕЛЬЗЯ присваивать целое число. это - символ.

Почему это? Для меня - char - это знаковый целый 8-битный тип. Почему туда нельзя помещать число? Очень даже можно. Не вижу ошибку.
А вообще код естественно приводит к ошибке - так было задумано.

2 korisk
Дело может в отладочной информации - компилер может помещать различные дополнительные данные в стек. Может даже специально разного размера. Надо попробовать в релиз откомпилить. Во-вторых - register - это рекомендация компилятору, никто не обещает, что это действительно так.

UPD не, релиз не помогает, падает на итерации от 0x1000 до 0x3000

[drBatty]

Для меня - char - это знаковый целый 8-битный тип.

для меня - тоже. с текущим моим железом, с текущей ОС, с текущим компилятором - пока ещё 8и битное знаковое целое. Однако, это вовсе не факт. В стандарте этого не прописано, того, сколько в char'е бит, 8 или 9. Вон, у Кнута 6 бит было в байте, и ничего - всё было очень чудно. Причём его программы прекрасно работали не зависимо от того, сколько в байте бит. В данном случае происходит преобразование данных(точнее может происходить), с потерей информации. Это может привести к ошибкам.
Конечно, в данном случае приводит к ошибке другое...
а именно то, что *a++ затирает стек, ведь ваша char b; имеет размер всего 4 байта, а цикл - бесконечный. на какой именно интерации программа рухнет, и как именно она рухнет - сказать сложно, содержимое стека случайно, и сильно зависит от того, что вы запускали перед вашей "программой", я такую "программу" даже и собирать не стану, а уж тем более - запускать.

[drBatty]

А вообще код естественно приводит к ошибке - так было задумано.

а вы отладчиком прогоните, если вам так это интересно

[NickLion]

А что там отладчиком прогонять? Пишем в стек. До тех пор пока не упадет. Зачем нужно? Ну, может, ТС хочет внедриться в программу через обвал стека - вот и исследует этот вопрос - интересует непредсказуемость.

[NickLion]

Для меня - char - это знаковый целый 8-битный тип.

для меня - тоже. с текущим моим железом, с текущей ОС, с текущим компилятором - пока ещё 8и битное знаковое целое. Однако, это вовсе не факт. В стандарте этого не прописано, того, сколько в char'е бит, 8 или 9. Вон, у Кнута 6 бит было в байте, и ничего - всё было очень чудно. Причём его программы прекрасно работали не зависимо от того, сколько в байте бит. В данном случае происходит преобразование данных(точнее может происходить), с потерей информации. Это может привести к ошибкам.

Да, но сказано, что char - это 1 байт. Почему не использовать его как малое целое число? С таким же успехом можно сказать, что размер long int не обязательно 32 бита и помещать туда 1 млрд. нельзя - могут быть ошибки на какой-нибудь системе, где байт 6 бит, а long int соответственно будет всего 24 бита.

[drBatty]

Да, но сказано, что char - это 1 байт.

как не странно, но в стандарте такого не было(и думаю - не появилось)
там написано только то, что размер char - 1 символ(не байт!), а длинна short, int, long не менее чем char

Код: Выделить всё

sizeof(char)=1
sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)

а сколько где бит стандартом не оговаривается. Насколько я знаю, это справедливо и в Си, и в С++.
я помню много кода правил, из-за того, что long был 16 бит, а стал 32. А я об этом по дурости не подумал
теперь - знаю точно.

А что там отладчиком прогонять? Пишем в стек. До тех пор пока не упадет. Зачем нужно? Ну, может, ТС хочет внедриться в программу через обвал стека - вот и исследует этот вопрос - интересует непредсказуемость.

ну что-то там затирается в стеке и всё падает.
это может пригодится при создании вирусов наверное... может и ещё для чего-нибудь такого деструктивного.

[korisk]

Поясню вопрос ещё раз )
Вопрос про способ запуска процесса. Почему используемый размер стека разный от запуска к запуску?.
в венде последнее выведенное число всегда оданаково.
Тип данных указателя не имеет значения. char я выбрал затем, чтобы измерить размер памяти от &b до вершины стека в sizeof(char).) )
рекомендация register отлично работает .. что проверено.

[drBatty]

Почему используемый размер стека разный от запуска к запуску?.

не, размер одинаковый, программа падает в разное время. что-то там в стеке критичное лежит, в разных местах, когда вы это затираете программа падает.

в венде последнее выведенное число всегда оданаково

неопределённое поведение не обязано быть разным. впрочем и одинаковым - тоже.

Тип данных указателя не имеет значения. char я выбрал затем, чтобы измерить размер памяти от &b до вершины стека в sizeof(char).) )

оригинально... разве нет другого метода? не такого суицидального...
man ld например..

Код: Выделить всё

--stack reserve
       --stack reserve,commit
           Specify the number of bytes of memory to reserve (and optionally commit) to be used as stack for this program.
           The default is 2Mb reserved, 4K committed.  [This option is specific to the i386 PE targeted port of the linker]

оно?

рекомендация register отлично работает .. что проверено.

лучше используйте static, это не рекомендация компилятору, а приказ хранить данные НЕ в стеке. а именно - в памяти программы. насколько я понимаю - затереть таким образом такую переменную так не удастся.

[korisk]

оно?

не, стек одинаков, но используется разная его доля.

[NickLion]

Да, но сказано, что char - это 1 байт.

как не странно, но в стандарте такого не было(и думаю - не появилось)
там написано только то, что размер char - 1 символ(не байт!), а длинна short, int, long не менее чем char

Код: Выделить всё

sizeof(char)=1
sizeof(char)<=sizeof(short)<=sizeof(int)<=sizeof(long)

а сколько где бит стандартом не оговаривается. Насколько я знаю, это справедливо и в Си, и в С++.
я помню много кода правил, из-за того, что long был 16 бит, а стал 32. А я об этом по дурости не подумал
теперь - знаю точно.

С конца начну.
1. long и был 32 бита. Это int менялся.
2. Смотрим: http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1256.pdf
Пункт 6.5.3.4 The sizeof operator
И видим:

2 The sizeof operator yields the size (in bytes) of its operand.
...
3 When applied to an operand that has type char, unsigned char, or signed char,
(or a qualified version thereof) the result is 1.

Так что меряют в байтах (Что логично - что такое символ, в общем-то, непонятно). И сказано что именно 1.

[Zeus]

Можно записывать число или нельзя...
А в какой тип данных не поместится 1?

[NickLion]

В void

[drBatty]

не, стек одинаков, но используется разная его доля.

да, конечно. но кроме того, его ещё и можно поменять. (размер стека).

1. long и был 32 бита. Это int менялся.

угу.
кстати, кто знает, что там сейчас с 64х битным типом?
int менялся, но int я никогда не писал, писал long, если надо... а так - ничего не писал... вот и правил согласен, свои грабли, сам расставил, сам наступил...
хотите - повторяйте мои ошибки.

Так что меряют в байтах (Что логично - что такое символ, в общем-то, непонятно). И сказано что именно 1.

хм... спасибо.

Можно записывать число или нельзя...
А в какой тип данных не поместится 1?

1 - можно. тут опасные грабли с преобразованием типов. что будет если записать

Код: Выделить всё

x = -1

вот и я не знаю... зависит от типа x.
тип -1 вроде как int, и просто единицы тоже. что компилятор сделает с

Код: Выделить всё

char y=1

я честно говоря не знаю точно... да и что это за символ - тоже не знаю. везде по разному.

В void

это как?
может в void* ?


PS: а вообще - поясню свою позицию - ваш код, пишите как хотите. просто лично мне проще, если мой работает одинаково везде. если не одинаково - это потенциальные грабли, на которые вы обязательно наступите. Если вам нужен код "на один раз" - есть bash. С, а тем более С++ - это не на один раз... Это многоразовый код. ИМХО.

[Crazy]

Лично я бы дизассемблировал исполняемые файлы в win/lin. А потом прогнал бы в соответствующем отладчике.

[drBatty]

Лично я бы дизассемблировал исполняемые файлы в win/lin. А потом прогнал бы в соответствующем отладчике.

я бы тоже...
только я ещё не сошёл с ума, ИМХО для определения размера стека не обязательно затирать стек...

[DaemonTux]

Помнитится были патчи на gcc для защиты стека.
Может быть в этом всё дело?

[Serg79]

Вопрос:
1. почему от запуска к запуску число итераций разное?
2. в другой форм: почему от запуска к запуску стек заполнятеся разными объемами данных.

Библиотечные функции ввода/вывода производят буферизацию ввода/вывода. При срабатывании "Segmentation Fault", stdio-шные буфера не сбрасываются.

Попробуйте после каждого вызова printf выполнять сброс stdout с помощью fflush(stdout), может поможет.

[Crazy]

Лично я бы дизассемблировал исполняемые файлы в win/lin. А потом прогнал бы в соответствующем отладчике.

я бы тоже...
только я ещё не сошёл с ума, ИМХО для определения размера стека не обязательно затирать стек...

Ну лучше бы спросить автора книжки.
IDA показывает почти одинаковую картину
ELF скомпилированный g++ -O2

Код: Выделить всё

.text:08048470 main            proc near              ; DATA XREF: _start+17o
.text:08048470
.text:08048470 arg_0           = byte ptr  4
.text:08048470
.text:08048470                 lea     ecx, [esp+arg_0]
.text:08048474                 and     esp, 0FFFFFFF0h
.text:08048477                 push    dword ptr [ecx-4]
.text:0804847A                 push    ebp
.text:0804847B                 mov     ebp, esp
.text:0804847D                 push    esi
.text:0804847E                 push    ebx
.text:0804847F                 push    ecx
.text:08048480                 sub     esp, 1Ch
.text:08048483                 mov     byte ptr [ebp-0Dh], 1
.text:08048487                 xor     eax, eax
.text:08048489                 lea     esi, [ebp-0Dh]
.text:0804848C                 lea     esi, [esi+0]
.text:08048490
.text:08048490 loc_8048490:                           ; CODE XREF: main+39j
.text:08048490                 mov     byte ptr [esi], 1
.text:08048493                 inc     esi
.text:08048494                 lea     ebx, [eax+1]
.text:08048497                 push    edx
.text:08048498                 push    eax
.text:08048499                 push    esi
.text:0804849A                 push    offset format  ; "%x %x\n"
.text:0804849F                 call    _printf
.text:080484A4                 mov     eax, ebx
.text:080484A6                 add     esp, 10h
.text:080484A9                 jmp     short loc_8048490
.text:080484A9 main            endp

PE скомпилированный mingw32-g++ -O2

Код: Выделить всё

.text:00401290 _main           proc near              ; CODE XREF: ___mingw_CRTStartup+E2p
.text:00401290
.text:00401290 var_9           = byte ptr -9
.text:00401290 argc            = dword ptr  8
.text:00401290 argv            = dword ptr  0Ch
.text:00401290 envp            = dword ptr  10h
.text:00401290
.text:00401290                 push    ebp
.text:00401291                 mov     eax, 10h
.text:00401296                 mov     ebp, esp
.text:00401298                 push    esi
.text:00401299                 push    ebx
.text:0040129A                 sub     esp, 10h
.text:0040129D                 and     esp, 0FFFFFFF0h
.text:004012A0                 call    sub_401720
.text:004012A5                 call    sub_4013C0
.text:004012AA                 mov     [ebp+var_9], 1
.text:004012AE                 xor     esi, esi
.text:004012B0                 lea     ebx, [ebp+var_9]
.text:004012B3                 lea     esi, [esi+0]
.text:004012B9                 lea     edi, [edi+0]
.text:004012C0
.text:004012C0 loc_4012C0:                            ; CODE XREF: _main+49j
.text:004012C0                 mov     byte ptr [ebx], 1
.text:004012C3                 inc     ebx
.text:004012C4                 mov     [esp+8], esi
.text:004012C8                 inc     esi
.text:004012C9                 mov     [esp+4], ebx
.text:004012CD                 mov     dword ptr [esp], offset aXX; "%x %x\n"
.text:004012D4                 call    printf
.text:004012D9                 jmp     short loc_4012C0
.text:004012D9 _main           endp

Виртуальный адрес получаем через lea, а потом в цикле движемся к границе сегмента стека. И движемся до тех пор, пока не попытаемся что-либо записать в сегмент с битом доступа только для чтение(например сегмент кода).

[Lyset]

Насколько я помню, случайный фактор при выделении памяти - один из методов защиты от взлома. В OpenBSD, ЕМНИП этому уделено особое внимание. В GCC или вообще в ядре Linux, видимо, используется подобный механизм.

[NickLion]

1. long и был 32 бита. Это int менялся.

угу.
кстати, кто знает, что там сейчас с 64х битным типом?

Код: Выделить всё

+-------------+----------+-----------+-----------+-----------+-----------+-----------+
| Архитектура |   char   | short int |    int    | long int  | long long |   void*   |
+-------------+----------+-----------+-----------+-----------+-----------+-----------+
| 16-bit      |    8     |    16     |    16     |    32     |    ---    |   16/32   |
+-------------+----------+-----------+-----------+-----------+-----------+-----------+
| 32-bit      |    8     |    16     |    32     |    32     |    64     |    32     |
+-------------+----------+-----------+-----------+-----------+-----------+-----------+
| 64-bit      |    8     |    16     |    32     |    64     |    64     |    64     |
+-------------+----------+-----------+-----------+-----------+-----------+-----------+

Это в gcc, а вообще, там неразбериха из-за того, что стандартом четко ничего не оговорено.

Можно записывать число или нельзя...
А в какой тип данных не поместится 1?

1 - можно. тут опасные грабли с преобразованием типов. что будет если записать

Код: Выделить всё

x = -1

вот и я не знаю... зависит от типа x.
тип -1 вроде как int, и просто единицы тоже. что компилятор сделает с

Код: Выделить всё

char y=1

Если мы говорим о C (не C++) то тип выражения 'a' - тоже int, не char. Так что Ваше беспокойство не совсем оправдано.

Код: Выделить всё

#include <stdio.h>
int main(int argc, char *argv[], char *env[]){
    printf( "%d\n ", sizeof( 'a' ) );
    return 0;
}

В С выводит "4", а в С++ - "1".

В void

это как?
может в void* ?

Это была шутка. Вот:

Код: Выделить всё

void func(){
    return 1; // error -- не влазит :)
}

PS: а вообще - поясню свою позицию - ваш код, пишите как хотите. просто лично мне проще, если мой работает одинаково везде. если не одинаково - это потенциальные грабли, на которые вы обязательно наступите. Если вам нужен код "на один раз" - есть bash. С, а тем более С++ - это не на один раз... Это многоразовый код. ИМХО.

Да никто не спорит, но неужели Вы пишете код, который учитывает, что short int не обязательно 16-битный тип? Это все можно, я понимаю, но не излишне ли? На сегодня если аппаратура с регистрами не кратными 2 и есть, то это какая-то встраиваемая техника.

[Женя Подсыпальников]

Но в сегменте стека область от &env до argv[argc] разное от запуска к запуску!!!

А не выведешь ли разницу (&argv[argc - 1] - &env)
и не отследишь ли,

что именно разница этих разниц от старта к старту -
и есть разница итераций до падения ?

Интересно !

[Crazy]

код однако пугающий. Уберите операторы типа i++, замените обычным присваиванием, не разберешь что вы там с чем творите

наверное я не ясно описал проблему (
Далее в цикле указатель инкрементируется до тех пор, пока запись в следующую ячейку не вызовет сегфолт.

И где по вашему должна находится эта ячейка?

[korisk]

Но в сегменте стека область от &env до argv[argc] разное от запуска к запуску!!!

А не выведешь ли разницу (&argv[argc - 1] - &env)
и не отследишь ли,

что именно разница этих разниц от старта к старту -
и есть разница итераций до падения ?

Интересно !

Уже сделал, разница - белый шум относительно 4332 char c отклонением примерно 4000 char.

Куда копать уже нашел:
/usr/include/elf.h
вектор auxv

Ещё вопрос:
LD_SHOW_AUXV=1 /bin/true
у всех правильно отрабатывает? Или с непечатными символами?