|

saruman

|

Сега се сетих, че преди 15-ина години, когато още използвах дебъгери, използвах DDD. Като гледам май е умрял, последен рилийз 2011. Гуд риданс, както казва народа...

На мен ми е интересно Евлампи с какво си дебъгва дот нета през конзолата,да не се окаже изведнъж,че всички шеладжии бацат само принтове

п.с.Другото любопитно е как ти дебъгваш чужд код,където няма принтове на точните места ? :)

С четене на кода и слагане на принтове, разбира се. Ти как го дебъгваш? Next, Next, Step, Next, Step?

Естествено,особено ако имаш memory corruption,това е най-лесният и бърз метод,те хората затова мятат разни изцепшъни и пишат гарбидж колектори и смарт поинтъри,само и само да не пишат принтове :)

Но и не отричам напълно логовете за дебъгване(застраховам се да не вляза в идиотите :)),има ситуации,в които принтовете са по-удобни от степването

saruman

|

saruman

|

Сега се сетих, че преди 15-ина години, когато още използвах дебъгери, използвах DDD. Като гледам май е умрял, последен рилийз 2011. Гуд риданс, както казва народа...

На мен ми е интересно Евлампи с какво си дебъгва дот нета през конзолата,да не се окаже изведнъж,че всички шеладжии бацат само принтове

п.с.Другото любопитно е как ти дебъгваш чужд код,където няма принтове на точните места ? :)

С четене на кода и слагане на принтове, разбира се. Ти как го дебъгваш? Next, Next, Step, Next, Step?

Естествено,особено ако имаш memory corruption,това е най-лесният и бърз метод,те хората затова мятат разни изцепшъни и пишат гарбидж колектори и смарт поинтъри,само и само да не пишат принтове :)

Но и не отричам напълно логовете за дебъгване(застраховам се да не вляза в идиотите :)),има ситуации,в които принтовете са по-удобни от степването

Най-бързия метод като имаш memory corruption е да пуснеш съответния туул, например valgrind.

|

saruman

|

saruman

|

Сега се сетих, че преди 15-ина години, когато още използвах дебъгери, използвах DDD. Като гледам май е умрял, последен рилийз 2011. Гуд риданс, както казва народа...

На мен ми е интересно Евлампи с какво си дебъгва дот нета през конзолата,да не се окаже изведнъж,че всички шеладжии бацат само принтове

п.с.Другото любопитно е как ти дебъгваш чужд код,където няма принтове на точните места ? :)

С четене на кода и слагане на принтове, разбира се. Ти как го дебъгваш? Next, Next, Step, Next, Step?

Естествено,особено ако имаш memory corruption,това е най-лесният и бърз метод,те хората затова мятат разни изцепшъни и пишат гарбидж колектори и смарт поинтъри,само и само да не пишат принтове :)

Но и не отричам напълно логовете за дебъгване(застраховам се да не вляза в идиотите :)),има ситуации,в които принтовете са по-удобни от степването

Най-бързия метод като имаш memory corruption е да пуснеш съответния туул, например valgrind.

На теория да,на практика при голям проект няма начин,кога ще го пускаш,при всеки къмит ли?Винаги може да насереш мемори адрес при някой корнер кейс,в който няма как да влезеш лесно рънтайм с валгринда (не умишлено,но примерно при някой глобален рефактор)

saruman

На теория да,на практика при голям проект няма начин,кога ще го пускаш,при всеки къмит ли?Винаги може да насереш мемори адрес при някой корнер кейс,в който няма как да влезеш лесно рънтайм с валгринда (не умишлено,но примерно при някой глобален рефактор)

Ще го пускаш когато намериш бъг. Ти кога дебъгваш, при всеки къмит ли?

|

saruman

На теория да,на практика при голям проект няма начин,кога ще го пускаш,при всеки къмит ли?Винаги може да насереш мемори адрес при някой корнер кейс,в който няма как да влезеш лесно рънтайм с валгринда (не умишлено,но примерно при някой глобален рефактор)

Ще го пускаш когато намериш бъг. Ти кога дебъгваш, при всеки къмит ли?

Има смисъл да се пуска само при специфични бъгове,при които не помага дебъгера,айде да вляза в твоята риторика - на 95% :D нулевият поинтър ще ти изгърми при опит за дереференциране,валгринга е супер тежък тул,не знам защо толкова му се кефиш,разни статични като адрес санитайзери са доста по-яки,макар и да се ползват за различни цели

saruman

|

saruman

На теория да,на практика при голям проект няма начин,кога ще го пускаш,при всеки къмит ли?Винаги може да насереш мемори адрес при някой корнер кейс,в който няма как да влезеш лесно рънтайм с валгринда (не умишлено,но примерно при някой глобален рефактор)

Ще го пускаш когато намериш бъг. Ти кога дебъгваш, при всеки къмит ли?

Има смисъл да се пуска само при специфични бъгове,при които не помага дебъгера,айде да вляза в твоята риторика - на 95% :D нулевият поинтър ще ти изгърми при опит за дереференциране,

Напротив, има смисъл да се пуска ВМЕСТО дебъгера. Напълно малоумно е да правиш next, next, step, next за memory corruption bugs.

saruman

валгринга е супер тежък тул,не знам защо толкова му се кефиш,разни статични като адрес санитайзери са доста по-яки,макар и да се ползват за различни цели

Това е невероятно ценно изказване, "А е по-добро от Б, макар и да се използва за различни цели".

|

saruman

|

saruman

На теория да,на практика при голям проект няма начин,кога ще го пускаш,при всеки къмит ли?Винаги може да насереш мемори адрес при някой корнер кейс,в който няма как да влезеш лесно рънтайм с валгринда (не умишлено,но примерно при някой глобален рефактор)

Ще го пускаш когато намериш бъг. Ти кога дебъгваш, при всеки къмит ли?

Има смисъл да се пуска само при специфични бъгове,при които не помага дебъгера,айде да вляза в твоята риторика - на 95% :D нулевият поинтър ще ти изгърми при опит за дереференциране,

Напротив, има смисъл да се пуска ВМЕСТО дебъгера. Напълно малоумно е да правиш next, next, step, next за memory corruption bugs.

Ами пробвай да пуснеш valgrind-a в един while(true) и ще разбереш какво имам предвид,дебъгера си зарежда дебъг сигналите,утежняват екзето или там квото е,ама не алокира памет динамично да проверява разни чънкове

saruman

|

Напротив, има смисъл да се пуска ВМЕСТО дебъгера. Напълно малоумно е да правиш next, next, step, next за memory corruption bugs.

Ами пробвай да пуснеш valgrind-a в един while(true) и ще разбереш какво имам предвид,дебъгера си зарежда дебъг сигналите,утежняват екзето или там квото е,ама не алокира памет динамично да проверява разни чънкове

Чакай сега, ти наистина ли си въобразяваш, че valgrind ще алокира памет ако имаш white(true)? Изпбщо, имаш ли идея как работи valgrind? А как работи дебъгера?

|

saruman

|

Напротив, има смисъл да се пуска ВМЕСТО дебъгера. Напълно малоумно е да правиш next, next, step, next за memory corruption bugs.

Ами пробвай да пуснеш valgrind-a в един while(true) и ще разбереш какво имам предвид,дебъгера си зарежда дебъг сигналите,утежняват екзето или там квото е,ама не алокира памет динамично да проверява разни чънкове

Чакай сега, ти наистина ли си въобразяваш, че valgrind ще алокира памет ако имаш white(true)? Изпбщо, имаш ли идея как работи valgrind? А как работи дебъгера?

Сори,забравих за даскалският ти манталитет,мисля,че new(malloc) се подразбира в while(true)

saruman

|

saruman

|

Напротив, има смисъл да се пуска ВМЕСТО дебъгера. Напълно малоумно е да правиш 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, не ми се е случвало. Иначе да, супер нещо е точно за проблеми от сорта на мазане по памет дето не трябва, неосвобождаване и прочее, конкретно в такива случаи има смисъл доста повече от дебъгване (дебъгване на какво точно).

gat3way

Не знам как точно работи valgrind, обаче е голяма забава с opencl код, в един приличен процент от случаите води до тръшване на системата, където няма оправия освен ребутване. Не знам как го прави това номер, но може би все пак е някоя тайна на amd-то на рънтайма, откакто минах на nvidia, не ми се е случвало. Иначе да, супер нещо е точно за проблеми от сорта на мазане по памет дето не трябва, неосвобождаване и прочее, конкретно в такива случаи има смисъл доста повече от дебъгване (дебъгване на какво точно).

Хмм, не знам, явно някой трябва да го дебъгне, по възможност с дебъгер. :)

|

saruman

|

saruman

|

Напротив, има смисъл да се пуска ВМЕСТО дебъгера. Напълно малоумно е да правиш next, next, step, next за memory corruption bugs.

Ами пробвай да пуснеш valgrind-a в един while(true) и ще разбереш какво имам предвид,дебъгера си зарежда дебъг сигналите,утежняват екзето или там квото е,ама не алокира памет динамично да проверява разни чънкове

Чакай сега, ти наистина ли си въобразяваш, че valgrind ще алокира памет ако имаш white(true)? Изпбщо, имаш ли идея как работи valgrind? А как работи дебъгера?

Сори,забравих за даскалският ти манталитет,мисля,че new(malloc) се подразбира в while(true)

Е, това е невероятно реалистичен случай. Определено си изисква дебъгер и next, next, step.

Ясно,явно не си особено запознат с материята след като повтаряш едни и същи клишета :)

Сигурно, мазохизъм има много на тоя свят. Все пак обаче съм склонен да обвиня амд за всички такива грехове, те са виновни също и за великото съобщение в dmesg което гласи просто "ASIC Hang" след което системата става абсолютно неизползваема освен през ssh, но пък дори през ssh като пуснеш нещо дето иска да има каквото и да било вземане-даване с gpu-то, отива за вечни времена в uninterruptable sleep.

saruman

Ясно,явно не си особено запознат с материята след като повтаряш едни и същи клишета :)

Изобщо не съм запознат. Изобщо от програмиране си нямам никаква идея. Дори не знам, че > и >= изпълняват същия брой инструкции.

Кой знае защо, обаче, мога да се оправям с кода на llvm и linux kernel. Мистерия!

gat3way

Сигурно, мазохизъм има много на тоя свят. Все пак обаче съм склонен да обвиня амд за всички такива грехове, те са виновни също и за великото съобщение в dmesg което гласи просто "ASIC Hang" след което системата става абсолютно неизползваема освен през ssh, но пък дори през ssh като пуснеш нещо дето иска да има каквото и да било вземане-даване с gpu-то, отива за вечни времена в uninterruptable sleep.

Хех, това е интересно. Някой си е оставил ръцете в драйвъра. Не че и аз не съм правил подобни грешки, wait_event вместо wait_event_interruptible. :)

Той драйвера си е затворен тъй че шансове никакви, ни с дебъгери ни с нищо :)

gat3way

Той драйвера си е затворен тъй че шансове никакви, ни с дебъгери ни с нищо :)

Хмм, Alt-SysRq и t/l би трябвало все нещо да покаже, надявам се.

|

saruman

Ясно,явно не си особено запознат с материята след като повтаряш едни и същи клишета :)

Изобщо не съм запознат. Изобщо от програмиране си нямам никаква идея. Дори не знам, че > и >= изпълняват същия брой инструкции.

Кой знае защо, обаче, мога да се оправям с кода на llvm и linux kernel. Мистерия!

Хаххаха,american bad ass,харесваш ми,хлъзгав си като жонката като го питам за средната заплата в русия извън москва

saruman

|

saruman

Ясно,явно не си особено запознат с материята след като повтаряш едни и същи клишета :)

Изобщо не съм запознат. Изобщо от програмиране си нямам никаква идея. Дори не знам, че > и >= изпълняват същия брой инструкции.

Кой знае защо, обаче, мога да се оправям с кода на llvm и linux kernel. Мистерия!

Хаххаха,american bad ass,харесваш ми,хлъзгав си като жонката като го питам за средната заплата в русия извън москва

E, не знам колко съм badass, но не дебъгвам memory corruption bugs с дебъгер поне откакто се появи ElectricFence.