0xfbad8001 Магическое число в трассировке

Я смотрю на следующую трассировку программы, которую я отлаживаю в GDB:

Thread 7 (Thread 3983):
#0  0xf7737430 in __kernel_vsyscall ()
#1  0x41b85412 in __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/i386/i486/lowlevellock.S:142
#2  0x41b80d6d in _L_lock_686 () from libpthread.so.0
#3  0xfbad8001 in ?? ()
#4  0x080eac80 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

В частности, меня интересует адрес кадра 0xfbad8001 и его значение.

Платформа основана на x86, поэтому этот невыровненный адрес недействителен. Учитывая, что «плохой» закодирован в шестнадцатеричном значении, я предполагаю, что это магическое число, но до сих пор я не смог определить, кто устанавливает это значение и почему. Я попытался найти ядро ​​и glibc в базе данных google и онлайн LXR, но не нашел ни одной строки кода, которая действительно устанавливала бы это значение.

Если я ищу в Google «fbad8001», то есть много обращений, показывающих этот адрес в обратных трассировках и дампах памяти. Таким образом, это конкретное значение, кажется, имеет какое-то значение, и я предполагаю, что это магическое число откуда-то, но до сих пор я не смог найти код, который его устанавливает.

Кто устанавливает это значение и что оно означает?

Ядро основано на Linux 3.4.10, а glibc — на 2.15.

Помимо исходного кода ядра и glibc, я также просмотрел исходный код gcc, gdb и binutils, но до сих пор не вижу никаких неопровержимых доказательств. Я не уверен, где еще искать.


c debugging gdb backtrace magic-numbers
person Digital Trauma    schedule 27.05.2014    source источник
comment
0x41b80d6d также является плохим (невыровненным) адресом.   -  person Paul R    schedule 28.05.2014
comment
Стек поврежден?   -  person Mooing Duck    schedule 28.05.2014
comment
@MooingDuck Возможно. Мой вопрос конкретно об адресе 0xfbad8001, который кажется слишком большим совпадением.   -  person Digital Trauma    schedule 28.05.2014
comment
@DigitalTrauma: если стек поврежден и это значение не является допустимым указателем, само собой разумеется, что это значение вообще не является указателем. Это может быть что угодно (или комбинация вещей) в stsack. См. stackoverflow.com/questions/4105120/what-is-undefined-behavior.   -  person Mooing Duck    schedule 28.05.2014
comment
@close-voter Возможно, я неправильно истолковываю область действия справочного центра, но почему программа, которую я отлаживаю в GDB, не связана с программированием?   -  person Digital Trauma    schedule 28.05.2014
comment
@MooingDuck Если я поищу в Google 0xfbad8001, то будет много обращений, показывающих этот адрес в обратных трассировках. Таким образом, это конкретное значение, кажется, имеет некоторое значение, что я и пытаюсь определить с помощью этого вопроса. Но, возможно, это просто случайное значение в стеке, как вы говорите.   -  person Digital Trauma    schedule 28.05.2014
comment
@DigitalTrauma: я также наблюдал его появление в различных (казалось бы, не связанных) обратных следах, хотя до сих пор у меня нет лучшего объяснения, чем случайность. Хотя вы меня заинтересовали. На самом деле, большая часть кода связана с сетью, может быть, это собственный код ошибки на каком-то сетевом устройстве?   -  person Mooing Duck    schedule 28.05.2014

Ответы (2)


arrow_upward
5
arrow_downward

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

Обратите внимание, что указанный выше адрес также не выровнен. Это говорит о том, что все, что вы читаете со стека оттуда, вызывает подозрение.

Я согласен, что значение fbad8001, скорее всего, выбрано, но не имеет большого значения. Если вы хотите продолжить расследование, вам нужно использовать подходящий инструмент отладки для непосредственной проверки стека. Вы должны быть в состоянии найти действительные кадры стека путем проверки (если они есть), и вы вполне можете найти несколько экземпляров этого значения (или других подобных недопустимых значений), заполняющих части стека, которые не предназначены для доступа.

Если это отладочная сборка, вы можете найти полосы таких значений в качестве часовых между кадрами стека. Если предыдущий фрейм стека поврежден, это значение может быть слишком большим. Вы не узнаете, пока не посмотрите.

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

person david.pfx    schedule 29.05.2014
comment
+1 Полезный совет, но я ищу более подробную информацию о том, откуда это на самом деле. Я просто назначаю награду за это, если вам интересно :) - person Digital Trauma; 30.05.2014
comment
Недостаточно информации, чтобы воспроизвести и диагностировать вашу конкретную ситуацию. Вы можете провести полнотекстовый поиск различных частей ядра Linux и GCC, или вам может повезти, и вы найдете человека, который это написал. Удачи. - person david.pfx; 30.05.2014
comment
Награждаю вас наградой, но не принимаю ваш ответ ;-) У меня до сих пор нет полного ответа на вопрос, но я ценю совет и ненавижу исчезновение очков награды. - person Digital Trauma; 06.06.2014

arrow_upward
1
arrow_downward

Недавно я наткнулся на ваш вопрос, когда отлаживал сбой, когда произошла та же самая подозрительная константа 0xFBAD8001.

В моем случае была локальная переменная, которая использовалась еще долго после того, как ее область действия была оставлена. Затем он был перезаписан фреймом стека функции printf(), и когда указатель снова использовался, структура содержала значение 0xFBAD8001.

Магическая константа взята из glibc, где она используется для флагов структурой _IO_FILE libio.
Половина старшего порядка содержит магическое значение 0xFBAD8000, остальное используется для флагов.
Вот почему было так сложно найти его в Google.

person Vitezslav Cizek    schedule 14.02.2018