0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Естествено,особено ако имаш memory corruption,това е най-лесният и бърз метод,те хората затова мятат разни изцепшъни и пишат гарбидж колектори и смарт поинтъри,само и само да не пишат принтове :)
Но и не отричам напълно логовете за дебъгване(застраховам се да не вляза в идиотите :)),има ситуации,в които принтовете са по-удобни от степването
Най-бързия метод като имаш memory corruption е да пуснеш съответния туул, например valgrind.
На теория да,на практика при голям проект няма начин,кога ще го пускаш,при всеки къмит ли?Винаги може да насереш мемори адрес при някой корнер кейс,в който няма как да влезеш лесно рънтайм с валгринда (не умишлено,но примерно при някой глобален рефактор)
Ще го пускаш когато намериш бъг. Ти кога дебъгваш, при всеки къмит ли?
Има смисъл да се пуска само при специфични бъгове,при които не помага дебъгера,айде да вляза в твоята риторика - на 95% :D нулевият поинтър ще ти изгърми при опит за дереференциране,валгринга е супер тежък тул,не знам защо толкова му се кефиш,разни статични като адрес санитайзери са доста по-яки,макар и да се ползват за различни цели
Напротив, има смисъл да се пуска ВМЕСТО дебъгера. Напълно малоумно е да правиш next, next, step, next за memory corruption bugs.
Това е невероятно ценно изказване, "А е по-добро от Б, макар и да се използва за различни цели".
Ами пробвай да пуснеш valgrind-a в един while(true) и ще разбереш какво имам предвид,дебъгера си зарежда дебъг сигналите,утежняват екзето или там квото е,ама не алокира памет динамично да проверява разни чънкове
Чакай сега, ти наистина ли си въобразяваш, че valgrind ще алокира памет ако имаш white(true)? Изпбщо, имаш ли идея как работи valgrind? А как работи дебъгера?
Сори,забравих за даскалският ти манталитет,мисля,че new(malloc) се подразбира в while(true)
Е, това е невероятно реалистичен случай. Определено си изисква дебъгер и next, next, step.
Не знам как точно работи valgrind, обаче е голяма забава с opencl код, в един приличен процент от случаите води до тръшване на системата, където няма оправия освен ребутване. Не знам как го прави това номер, но може би все пак е някоя тайна на amd-то на рънтайма, откакто минах на nvidia, не ми се е случвало. Иначе да, супер нещо е точно за проблеми от сорта на мазане по памет дето не трябва, неосвобождаване и прочее, конкретно в такива случаи има смисъл доста повече от дебъгване (дебъгване на какво точно).
Хмм, не знам, явно някой трябва да го дебъгне, по възможност с дебъгер. :)
Ясно,явно не си особено запознат с материята след като повтаряш едни и същи клишета :)
Сигурно, мазохизъм има много на тоя свят. Все пак обаче съм склонен да обвиня амд за всички такива грехове, те са виновни също и за великото съобщение в dmesg което гласи просто "ASIC Hang" след което системата става абсолютно неизползваема освен през ssh, но пък дори през ssh като пуснеш нещо дето иска да има каквото и да било вземане-даване с gpu-то, отива за вечни времена в uninterruptable sleep.
Изобщо не съм запознат. Изобщо от програмиране си нямам никаква идея. Дори не знам, че > и >= изпълняват същия брой инструкции.
Кой знае защо, обаче, мога да се оправям с кода на llvm и linux kernel. Мистерия!
Хех, това е интересно. Някой си е оставил ръцете в драйвъра. Не че и аз не съм правил подобни грешки, wait_event вместо wait_event_interruptible. :)
Той драйвера си е затворен тъй че шансове никакви, ни с дебъгери ни с нищо :)
Хмм, Alt-SysRq и t/l би трябвало все нещо да покаже, надявам се.
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
