This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I don't know it is a common problem or not. But on my home machine Run fails very often (in ~50% cases) on some of projects. Ubuntu 10.04 (latest unstable build) HelloQtProject Profiler: C/C++ Simple Indicator Console Type: Output Window Run works stable If profiler is switched off or "C/C++ Oracle Solaris Studio Standard" tool is selected or program is started in external terminal
Created attachment 98450 [details] Program terminated with signal 4, Illegal instruction.
Created attachment 98451 [details] Program terminated with signal 4, Illegal instruction
Quick googling gave this: https://bugzilla.redhat.com/show_bug.cgi?id=519081 What is the version of glibc and binutils on that machine?
http://en.wikipedia.org/wiki/Eglibc
eglibc-2.11.1 binutils-2.20.1
A interesting bug mentioning race condition in dynamic loader: https://bugzilla.redhat.com/show_bug.cgi?id=222288 Valera, does setting LD_BIND_NOW=1 help?
nice!!! thanks
Valera, I'd appreciate if you filed a bug against Ubuntu. It would be very interesting to see their evaluation of the problem.
ok
https://bugs.launchpad.net/ubuntu/+source/netbeans/+bug/578880
Ubuntu 10.10 is supported platform in next release (http://wiki.netbeans.org/NetBeans_610_Supported_Platforms) At home I installed Ubuntu x64 10.10RC, but this problem is not disappeared (run fails very often). Before Ubuntu's release I mark this bug as P2. P.S. Also this bug can be upgraded to P1 after Ubuntu 10.10 release.
Is there a core dump from Ubuntu 10.10 where the bug is fixed? The 10.04 core dumps are sort of useless as I see no traces of our profiler in it.
(gdb) where #0 _dl_x86_64_restore_sse () at ../sysdeps/x86_64/dl-trampoline.S:222 #1 0x00007f87e3661c15 in _dl_fixup (l=<value optimized out>, reloc_arg=<value optimized out>) at ../elf/dl-runtime.c:126 #2 0x00007f87e3668825 in _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:41 #3 0x00007f87e3450803 in check_control () from /home/sova/.netbeans/6.9/tools/Linux-x86_64/bin/prof_agent.so #4 0x00007f87e3450c14 in reporter () from /home/sova/.netbeans/6.9/tools/Linux-x86_64/bin/prof_agent.so #5 0x00007f87e2a1292d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #6 0x0000000000000000 in ?? ()
unable to reproduce on 10.10, but almost 100% on 10.04, Valeriy, please recheck
It seems to me, that this issue depends on number of processor cores. 1-2 - it's ok, >2 - run fails (Ubuntu 10.04 LTS).
Again I checked this issue on my Core 2 Quad (4 cores) and NetBeans fails in Ubuntu 10.10 also.
It looks as shared object initialization/binding bug in Ubuntu. The only thing we can try is to somehow postpone profiler thread creation in profiler init. This could prevent a call to not yet initialized system library. Honestly speaking I'm not sure it will work (we are already using clone() instead of pthread_craeate()) and if it is doable (as there could be no event we can intercept and use to create a thread).
Can we just disable simple profiler for Ubuntu 10.x for a time being? And downgrade the bug.
Andrew, please disable it on ubuntu
LL_TOOL is disabled on Ubuntu (by default). Still -J-DDISABLE_LL_TOOL_ON_UBUNTU=false could be used to switch it on. Changeset: cnd-main/183158:f29fdc45286e Valera, could you, please try it and in case it makes things to be more stable (looks like it does), lower the priority of the issue. Thanks, =Andrew
Yes.Run works stably with this fix
lowing the priority then... Thanks!
i'm on ubuntu 10.10 and the profiler ("show profiling indicators during run") was enabled by default, and i was getting the 132 errors - C/C++ project with existing sources, using the automatic configuration mode also, not sure disabling this setting by default is sufficient. maybe mention it in the release notes or a warning when a program is run with that box checked on ubuntu. in this case, 132 is a rare enough number that google finds this bug and the workaround quickly - but we really shouldn't be relying on that ...
Can you please tell us more about this "132 error"? Frankly speaking we do not know what exactly is causing the issue. It either something that changed in Ubuntu dynamic loader or in system libraries. Somehow our library is triggering this bug while there is nothing violation standards and conventions in it. So, some additional information can help a lot.
*** Bug 193669 has been marked as a duplicate of this bug. ***
*** Bug 199358 has been marked as a duplicate of this bug. ***
I can verify that it is a race condition. By modifying dorun.sh and putting in a one second delay it works almost all of the time. A two second delay makes it always work. I am on arch linux up-to-date with beans 7.0
Not valid anymore... Now profiling is disabled...