В глаза сразу бросается
f==NULL
вместо
if(!f)

Вы нашли разницу?

P.S. Если причина не в говнокоде, значит разрабы изменили формат прошивки.

Лол, валяюсь с постановки вопроса просто. Мало того, что без железки, как я понимаю, разобраться в проблеме будет сложно, так ещё и нет бектрейса, не понятно, что за «147 строчка» такая + какие то доводы левые про NULL. Всё в традициях дебилолора

Что ж, попробую конечно, на приложенное барахло глянуть.

Отлично, там даже корки нету

Если segfault после INFO, то покажи хоть, что в filename и prefix

Не совсем понятно a) где крашится программа (на десктопе/сервере или на устройстве под управлением openwrt). b) Где строчка №147 ? с) Сборка дебаг или релиз ?

Где строчка №147

Я посмотрел, что это INFO. Вот и заинтересовался, что там за filename такой (допуская, что с самим INFO всё OK)

Дамп

а) Программа крашиться на десктопе, т.к. прошивка разбирается на составляющие на ПК.

б) В файле fwsplit.c

в) Релиз, сегодня 3 часа собирал этот «тулчейн» от разработчиков железки.

filename берется из начала файла прошивки туда сохраняется разметка разделов прошивки XM.ar7240.v5.5.8.20991.140205.1824.txt

prefix вроде как цифровая версия прошивки, но не уверен.

Разница стилистическая :-)

Ога, а собрать с -g для начала никак? )

Лучше покажи, что у тебя в момент сегфолта в filename и prefix (покажи первые байты до \0, убедись, что там всё, что нужно, и что \0 там есть). Сложно судить о багах, не имея ни нормальных бинарников, ни, собственно, твоего железа

//1234

в) Релиз, сегодня 3 часа собирал этот «тулчейн» от разработчиков железки.

Если релиз то то что тебе говорит gdb не всегда соотвецтвует действительности (строчка может быть обсалютно другой из за оптимизации). Если есть возможность сразу все пересоберите в дебаге (-g -O0) возможно стектрейс будет совсем другим. И можно запустить под valgrind чтоб всякие переполнения/ошибки адресации убрать ...

может у вас в prefix нету завершающего 0 и сегфолт происходит там (когда snprintf пытается отыскать конец строчки prefix)? а в стеке вы видете строчку 147 потомучто собрано с оптимизацией (такое бывает часто).

Тогда ты как будто что-то не договариваешь.

Сделай в gdb x/50xb filename, например, сразу после краша. Только собери сначала с -O0 -g

INFO это обычный fprintf. Упасть он может только из-за левого filename

пересоберите в дебаге

Дык систему сборки эту вижу первый раз в жизни, в мейкфайлах путаюсь...

Кому интересно ссылка на тулчейн.

Повторюсь, железо тут не причем то, что сегфолтиться собирается по ПКшную архитектуру.

core смотрел?

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

И твоя «147 строчка» не при чём. Там на верху стека совсем другая функция лежит. В общем, телепаты ушли в отпуск

С дебагом

Да, поторопился. Со 147-й

лиспер, раскажи в паре фраз, как это смотреть и в чём, хочу поучавствовать.

Дамп до кучи.

gdb, lol

я ожидал чего то типа

1) gdb ~/Загрузки/dump
2) bt
3) на строчке 35 видишь вызов какая ф-ция на стеке.

причём в п1. хотелось бы какой именно файл из предоставленных топикстартером запускать чтобы поглядеть и на что глядеть

Ты куда-нибудь в нормальное место не мог исходники выложить? Хотя бы на pastebin, если нелады с VCS.

Просто bt. И он пишет do_fwsplit(). Also info reg и objdump -d filename дадут место, где вышла ошибка. К сожалению, больше ничего сказать не могу, даже с отладочными символами он не хочет ничего показывать, видимо из-за разных версий библиотек (линукс же, ага, у каждого свой огород). Бинарь называется fwsplit.

Работка явно неблагодарная. Лучше бы ТС сам вывел, что показывает bt, list, далее по обстоятельствам. Если у ТС'а есть гмыло, могу в близжайший час поговорить с ним через встроенный жаббер, потом я спать пойду

если нелады с VCS.

А где ты тут видишь версии, альтернативно одаренный?

Есть желание, давай гмыло или жаббер, но только если быстро, а то я скоро спать

спс

Иди в жопу!

Я насчет того, что не собираюсь качать какой-то странный архив и распаковывать его, чтобы посмотреть 3 строчки кода!

что не собираюсь качать какой-то странный архив и распаковывать его, чтобы посмотреть 3 строчки кода!

Ну и никто не собрался бы, просьба о помощи составлена как-то абы как. С другой стороны, почему бы и не помочь человеку?

http://pastebin.com/1yY4tdBK

http://pastebin.com/xzpJQaZt

http://pastebin.com/195MbXEy

Прошу!

Аналогично. Завтра рано на работу.

Если что, на неделе сам поработаю, скину сюда выхлопы.

А, ну ок. Удачи. Смотри bt, list и делай print или x с аргументами тех комманд/функций, которые будут на строчке, вызвавшей ошибку. Если окажется, что значения ошибочные, смотри в какой функции они вычисляются (может, понадобится frame)

1. Что такое ubnt-mkfwimage?
2. Есть "фирмварь" для образца, чтобы хоть как-то воспроизвести?

1. Утилита для сбора прошивки после модификации из 4 сквошей.

2.«Фирмварь» по ссылке в первом сообщении ;-)

Ничего не найдено
Возможно, владелец удалил файлы или закрыл к ним доступ.

Я правильно понял, что код не твой, у кого-то он нормально работал, но у тебя падает? Может, проблема в "фирмвари"? Скажем, где-то забыли ввести проверку на реальный размер + преобразование типа ntohl и в итоге — бумц.

У меня все нормально открывает, странно.

Код не мой. Падает у всех, кто им пользуется (а это те кто прошивает точки доступа на 5 Ггц).

Просто, если закомментить создание файла с таблицей разделов в прошивке, сами разделы он извлекает, но в конце сегфолтиться.

Это такой обходной путь у ребят, которые его юзают как есть.

Возможно, действительно, проблема в образе.

Сейчас перезалью на Dropbox

Backtrace

gdb list

for (i = 0; i < fw->part_count; ++i) {
156                     fwp = &fw->parts[i];
157
158                     fprintf(f, "%s\t\t0x%02X\t0x%08X\t0x%08X\t0x%08X\t0x%08X\t%s.%s\n",
159                             fwp->header->name, 
160                             ntohl(fwp->header->index),
161                             ntohl(fwp->header->baseaddr),
162                             ntohl(fwp->header->part_size),

Цикл

for (i = 0; i < fw->part_count; ++i) {
		fwp = &fw->parts[i];

		fprintf(f, "%s\t\t0x%02X\t0x%08X\t0x%08X\t0x%08X\t0x%08X\t%s.%s\n",
			fwp->header->name,
			ntohl(fwp->header->index),
			ntohl(fwp->header->baseaddr),
			ntohl(fwp->header->part_size),
			ntohl(fwp->header->memaddr),
			ntohl(fwp->header->entryaddr),
			prefix, fwp->header->name);
	}

Похоже, у тебя фирмварь битая.

Воткнул перед fprintf вот это: printf("%s\n", fwp->header->name);. Сегфолт.

В общем, действительно, битая фирмварь: сообщает, что там 4 куска, а на деле их три.

Это разрабы нашаманили так от восточноевропейских Кулибиных :-D

Не подскажите, как это обойти?

З.Ы. Такой вот реверс )

P.S. Как обычно, обнаружил методом тыка. Потому как с gdb я вообще не дружу. А уж valgrind для меня — страх и ужас!

Спасибо за помощь!

Не зря я Вас кастовал

Взять оригинальный контент (из чего собрали фирмварь) и собрать ее правильно.

Либо пропатчить: "s/fw->part_count/fw->part_count - 1/g" (ХЗ, может и не поможет, там много чего надо править).

А вообще, по-хорошему, ледует переделать код: как минимум, добавить проверку размеров блоков (т.е. если тебе в структуре данных дают значение "прочитай 4 члена", а по факту их три, то хотя бы материться и говорить, что неправильный бинарник подсунули).

Правда тут же есть такое

#define MAX_SECTIONS	4

Не поэтому ли?

Взять оригинальный контент (из чего собрали фирмварь) и собрать ее правильно.

Если бы это было возможно, я не ковырялся бы с бинарником :-(

Значит, при формировании бинаря в fw->part_count вместо реального числа запихали это.

Ну дык, по логике вещей - поменять на «тройку» и усё?

Ведь так?

Попарсил ubnt-mkfwimage — на первый взгляд нет косяков с формированием файла. В общем, каким-то образом таки сформировали хрен знает что.

Только для данного варианта. Ты лучше сразу бинарь подрихтуй.