Оценка размера стека
Это WORKS ..
Помните, что в первый раз, когда вы напечатаете передаваемое значение, вы получите нуль, вы можете использовать его после загрузки Windows, то же самое для всего, что вы хотите кодировать для любого другого компонента.
Первый контроллер
try { Stage st = new Stage(); FXMLLoader loader = new FXMLLoader(getClass().getResource("/com/inty360/free/form/MainOnline.fxml")); Parent sceneMain = loader.load(); MainOnlineController controller = loader.<MainOnlineController>getController(); controller.initVariable(99L); Scene scene = new Scene(sceneMain); st.setScene(scene); st.setMaximized(true); st.setTitle("My App"); st.show(); } catch (IOException ex) { Logger.getLogger(LoginController.class.getName()).log(Level.SEVERE, null, ex); }Другой контроллер
public void initVariable(Long id_usuario){ this.id_usuario = id_usuario; label_usuario_nombre.setText(id_usuario.toString()); }
10 ответов
Runtime-Evaluation
Онлайн-метод заключается в том, чтобы нарисовать весь стек определенным значением, например, 0xAAAA (или 0xAA, независимо от вашей ширины). Затем вы можете проверить, насколько большая стопка максимально увеличилась в прошлом, проверив, какая часть картины осталась нетронутой.
Взгляните на эту ссылку для объяснения с иллюстрацией.
Преимущество в том, что это просто. Недостатком является то, что вы не можете быть уверены, что размер вашего стека в конечном итоге не превысит количество используемого стека во время вашего тестирования.
Статическая оценка
Есть несколько статических проверок, и я думаю, что существует даже взломанная версия gcc, которая пытается сделать это. Единственное, что я могу вам сказать, это то, что статическую проверку очень сложно выполнить в общем случае.
Также посмотрите этот вопрос.
Вы можете использовать инструмент статического анализа, например StackAnalyzer , если ваша цель соответствует требованиям.
Как обсуждалось в ответе на на этот вопрос , распространенным методом является инициализация стека с известным значением, а затем некоторое время запускать код и смотреть, где останавливается паттерн.
Не уверен на 100%, но я думаю, что это тоже можно сделать. Если у вас открыт порт jtag, вы можете подключиться к Trace32 и проверить максимальное использование стека. Хотя для этого вам придется дать начальный довольно большой произвольный размер стека.
If you want spend significant money you can use a commercial static analysis tool like Klocwork. Although Klocwork is primarily aimed at detecting software defects and security vulnerabilities. However, it also has a tool called 'kwstackoverflow' that can be used to detect stack overflow within a task or thread. I'm using for the embedded project that I work on, and I have had positive results. I don't think any tool like this is perfect, but I believe these commericial tools are very good. Most of the tools I have come across struggle with function pointers. I also know that many compiler vendors like Green Hills now build similar functionality right into their compilers. This is probably the best solution because the compiler has intimate knowledge of all the details needed to make accurate decisions about the stack size.
If you have the time, I'm sure you can use a scripting language to make your own stack overflow analysis tool. The script would need to identify the entry point of the task or thread, generate a complete function call tree, and then calculate the amount of stack space that each function uses. I suspect there are probably free tools available that can generate a complete function call tree so that should make it easier. If you know the specifics of your platform generating the stack space each function uses can be very easy. For example, the first assembly instruction of a PowerPC function often is the store word with update instruction that adjusts the stack pointer by the amount needed for the function. You can take the size in bytes right from the first instruction which makes determining the total stack space used relatively easy.
These types of analysis will all give you an approximation of the worst case upper bound for stack usage which is exactly what you want to know. Of course, pundits (like the ones I work with) might complain that you're allocating too much stack space, but they are dinosaurs that don't care about good software quality :)
One other possibility, although it doesn't calculate stack usage would be to use the memory management unit (MMU) of your processor (if it has one) to detect stack overflow. I have done this on VxWorks 5.4 using a PowerPC. The idea is simple, just put a page of write protected memory at the very top of your stack. If you overflow, a processor execption will occur and you will quickly be alerted to the stack overflow problem. Of course, it doesn't tell you by how much you need to increase the stack size, but if your good with debugging exception/core files you can at least figure out the calling sequence that overflowed the stack. You can then use this information to increase your stack size appropriately.
-djhaus
Статическая (автономная) проверка стека не так сложна, как кажется. Я реализовал его для нашей встроенной IDE ( RapidiTTy ) - в настоящее время он работает для ARM7 (NXP LPC2xxx), Cortex-M3 (STM32 и NXP LPC17xx), x86 и нашего собственного MIPS ISA-совместимого программного обеспечения FPGA. core.
По сути, мы используем простой анализ исполняемого кода для определения использования стека каждой функцией. Наиболее значимое выделение стека выполняется в начале каждой функции; просто убедитесь, что вы видите, как он изменяется с различными уровнями оптимизации и, если применимо, наборами инструкций ARM / Thumb и т. д. Помните также, что задачи обычно имеют свои собственные стеки, а ISR часто (но не всегда) совместно используют отдельную область стека!
После использования каждой функции она ' Достаточно легко построить дерево вызовов из синтаксического анализа и вычислить максимальное использование для каждой функции. Наша IDE генерирует планировщики (эффективные тонкие ОСРВ) для вас, поэтому мы точно знаем, какие функции обозначены как «задачи», а какие - как ISR, поэтому мы можем определить наихудшее использование для каждой области стека.
Конечно, эти цифры почти всегда превышают фактический максимум. Подумайте о функции вроде sprintf , которая может использовать лот стека, но сильно различается в зависимости от строки формата и параметров, которые вы предоставляете. Для этих ситуаций вы также можете использовать динамический анализ - заполните стек известным значением при запуске, затем запустите на некоторое время в отладчике, сделайте паузу и посмотрите, какая часть каждого стека все еще заполнена вашим значением (тестирование стиля с высоким водяным знаком) .
Не бесплатно, но Coverity выполняет статический анализ стека.
Мы пытались решить эту проблему на встраиваемой системе на моей работе. Это сошло с ума, слишком много кода (как нашего собственного, так и стороннего фреймворка), чтобы получить надежный ответ. К счастью, наше устройство было основано на Linux, поэтому мы вернулись к стандартному поведению, давая каждому потоку 2 МБ и позволяя диспетчеру виртуальной памяти оптимизировать использование.
Наша единственная проблема с этим решением заключалась в том, что один из инструментов сторонних производителей выполнил mlock на всем пространстве своей памяти (в идеале для повышения производительности). Это привело к тому, что все 2 МБ стека для каждого потока его потоков (75-150 из них) были выгружены. Мы потеряли половину нашей памяти, пока не выяснили это и не закомментировали проблемную строку.
Sidenote: Linux's диспетчер виртуальной памяти (vmm) выделяет оперативную память блоками по 4 КБ. Когда новый поток запрашивает 2 МБ адресного пространства для своего стека, vmm назначает фиктивные страницы памяти всем страницам, кроме самой верхней. Когда стек превращается в поддельную страницу, ядро обнаруживает сбой страницы и меняет поддельную страницу на настоящую (что потребляет еще 4 КБ оперативной памяти). Таким образом, стек потока может вырасти до любого необходимого размера (если он '
Это не автономный метод, но в проекте, над которым я работаю, у нас есть команда отладки, которая считывает максимальную отметку на всех стеках задач в приложении. Это выводит таблицу использования стека для каждой задачи и доступного запаса. Проверка этих данных после 24-часового прогона с большим количеством взаимодействий с пользователем дает нам некоторую уверенность в том, что определенное распределение стека «безопасно».
Это работает с использованием хорошо испытанной техники заполнения стеков известным шаблоном и при условии, что единственный способ, которым это может быть переписано, - это обычное использование стека, хотя, если это записывается любым другим способом, стек переполнение - меньшая из ваших проблем!
Помимо некоторых уже сделанных предложений, я хотел бы отметить, что часто во встроенных системах вам нужно жестко контролировать использование стека, потому что вам нужно размер стека при разумном размере.
В некотором смысле, использование пространства стека немного похоже на выделение памяти, но без (простого) способа определить, удалось ли ваше выделение, поэтому отсутствие контроля за использованием стека приведет к бесконечной борьбе за выяснение, почему ваша система снова падает. Так, например, если ваша система выделяет память для локальных переменных из стека, либо выделите эту память с помощью malloc (), либо, если вы не можете использовать malloc (), напишите свой собственный обработчик памяти (что является достаточно простой задачей).
Нет-нет:
void func(myMassiveStruct_t par)
{
myMassiveStruct_t tmpVar;
}
Да-да:
void func (myMassiveStruct_t *par)
{
myMassiveStruct_t *tmpVar;
tmpVar = (myMassiveStruct_t*) malloc (sizeof(myMassicveStruct_t));
}
Кажется довольно очевидным, но часто это не так, особенно когда вы не можете использовать malloc ().
Конечно, у вас все равно будут проблемы, так что это просто помогает, но не решает вашу проблему. Однако это поможет вам оценить размер стека в будущем, поскольку после того, как вы найдете подходящий размер для своих стеков, а затем, после некоторых изменений кода,