Два дня назад процесс обнаружения проблемы сбоя встроенного приложения был чрезвычайно сложным. Сначала для захвата основного файла использовался jlink, а затем для восстановления сцены использовалась трассировка 32. Наконец, было обнаружено, что стек задач не работает. на простаивающий поток наступили, но не было возможности определить, кто на него наступил. Память, по идее, зависит от краха d. Умп также может восстановить явление, вызванное какой операцией, но это чрезвычайно сложно. Необходимо использовать SP для восстановления стеков задач других потоков, что приводит к сбою, вызванному наступлением на память. Обычно стеки задач ступенчатые. on восстанавливаются, и в конце концов вам все равно придется полагаться на печать журналов и просмотр кода, чтобы выяснить, кто сделал плохой поступок;

В итоге было обнаружено, что аномальный код содержал несколько похожих структур. При выполнении операции сдвига тип структуры был написан неправильно. Следующий код:

    if (g_tag_sms_manager.cacheSize != 0 && g_tag_sms_manager.cacheStartIndex > 0) {
        for(int i= 0; i < g_tag_sms_manager.cacheSize; i++) {
            memcpy((void *)&g_tag_sms_manager.brodcastDigest[i], (void *)&g_tag_sms_manager.brodcastDigest[g_tag_sms_manager.cacheStartIndex+i],
            sizeof(uwb_sms_digest));
        }
    }

Ключ — sizeof(uwb_sms_digest). Указанный здесь размер определяет размер источника и цели копии. Поскольку это код копирования и вставки, мой коллега забыл изменить тип структурной переменной и использовал ее напрямую. как еще одна структура. sizeof(tag_uwb_sms_t), из-за чего чтение и запись выходят за пределы, и последствия, естественно, непредсказуемы!

Как программист со стажем более десяти лет, я чувствую себя беспомощным, когда происходит эта ошибка низкого уровня! Наши коллеги рассказали, что для реализации этого требования логика алгоритма отлаживалась две недели, за это время было решено множество подобных проблем с памятью!

На самом деле приведенный выше код и алгоритм не сложны. Это всего лишь обработка, постановка в очередь, сортировка и удаление из очереди коротких сообщений. Говоря о генеративном искусственном интеллекте, недавно выпущенном Baidu, сказал Вэнь Синь, вы не узнаете, пока не попробуете. Попробовав его, вы обнаружите, что это действительно очень мощно. Его использование может не только повысить производительность, но и улучшить стабильность продукта.

Код, сгенерированный Вэнь Синьианом:

Код очень полный, понимание задачи тоже очень хорошее, в коде нет низкоуровневых проблем!

Так в чем же ценность программистов?

1. Способность понимать потребности, решать проблемы и задавать вопросы;

То есть Вэнь Синьиян задает конкретные вопросы, а Вэньсиньянь дает соответствующие коды, отвечающие требованиям;

2. Возможности системной интеграции;

Ведь то, что мы разрабатываем, — это не просто кусок кода, а сложная система, а программисты — это те, кто инкапсулирует эти фрагменты кода через соответствующие интерфейсы и объединяет их в сложную систему;

3. Как уже упоминалось выше, если у вас больше нет этих способностей, не останется ли у вас другого выбора, кроме как потерять работу?

Так говорят пессимисты.

Эта статья является оригинальной статьей Guiniu Notes. Для перепечатки обращаться ко мне не обязательно, но, пожалуйста, укажите, что она взята из Guiniu Notes, it3q.com.

• Предыдущая статья: Больше нет
• Следующая статья: Скорость SPI DW1000