Hi all, In revision 223114 I committed a fix to clang project. It caused fail on clang-native-arm-cortex-a9: http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/23599. According to logs it was a problem with memory allocated by malloc. Reverting the fix in 223120 made the bot green. The changed code does nothing with heap, none of other bots failed, so it looks like a platform specific problem. Could somebody advice how I can investigate the problem? I don't have appropriate hardware and running tests in emulated environment does not shows any problem, all tests pass. Thank you! --Serge -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/234ae20b/attachment.html>
On 10 December 2014 at 19:06, Serge Pavlov <sepavloff at gmail.com> wrote:> In revision 223114 I committed a fix to clang project. It caused fail on > clang-native-arm-cortex-a9: > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/23599. > According to logs it was a problem with memory allocated by malloc. > Reverting the fix in 223120 made the bot green. The changed code does > nothing with heap, none of other bots failed, so it looks like a platform > specific problem.Hi Serge, We're seeing this behaviour, too, and on unrelated commits. We're working to make that bot more stable. That same commit passed on another ARM bot: http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/2123 which means that it probably had nothing to do with your commit, but the bot's instability. I suggest that, for the time being, if you see a failure in one ARM bot, check the others to make sure the problem can be reproduced across the board. If all fail, revert your patch and we'll try to debug. If only one fail but not the other, wait until the next build finishes. If the build is still broken the same way, revert. If not, ignore.> Could somebody advice how I can investigate the problem? I don't have > appropriate hardware and running tests in emulated environment does not > shows any problem, all tests pass.If the problem persists and you need to debug the problem, let me know and I could give you temporary access to an ARM board, or even run that for you. Alternatively, there is a new cloud service that I'm testing (https://cloud.online.net/) that provides remote *real* ARM boards for testing. They have a 15 minute trial that you could run some examples and retrieve the logs. cheers, --renato
Hi Renato, Thank you very much for the directions, I am going to recommit my fix. What are hardware used in buildbots? Are these common boards like PandaBoard or some thing special? What is RAM installed? Thanks, --Serge 2014-12-11 2:36 GMT+06:00 Renato Golin <renato.golin at linaro.org>:> On 10 December 2014 at 19:06, Serge Pavlov <sepavloff at gmail.com> wrote: > > In revision 223114 I committed a fix to clang project. It caused fail on > > clang-native-arm-cortex-a9: > > > http://lab.llvm.org:8011/builders/clang-native-arm-cortex-a9/builds/23599. > > According to logs it was a problem with memory allocated by malloc. > > Reverting the fix in 223120 made the bot green. The changed code does > > nothing with heap, none of other bots failed, so it looks like a platform > > specific problem. > > Hi Serge, > > We're seeing this behaviour, too, and on unrelated commits. We're > working to make that bot more stable. > > That same commit passed on another ARM bot: > > http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/2123 > > which means that it probably had nothing to do with your commit, but > the bot's instability. I suggest that, for the time being, if you see > a failure in one ARM bot, check the others to make sure the problem > can be reproduced across the board. > > If all fail, revert your patch and we'll try to debug. If only one > fail but not the other, wait until the next build finishes. If the > build is still broken the same way, revert. If not, ignore. > > > > Could somebody advice how I can investigate the problem? I don't have > > appropriate hardware and running tests in emulated environment does not > > shows any problem, all tests pass. > > If the problem persists and you need to debug the problem, let me know > and I could give you temporary access to an ARM board, or even run > that for you. > > Alternatively, there is a new cloud service that I'm testing > (https://cloud.online.net/) that provides remote *real* ARM boards for > testing. They have a 15 minute trial that you could run some examples > and retrieve the logs. > > cheers, > --renato >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20141211/3d48497f/attachment.html>