I'm still trying to hunt down where this SIGILL I'm hitting is coming from, and the next obstacle I've hit is some missing debuginfo packages, specifically: libGLEW-debuginfo libXau-debuginfo libXext-debuginfo mesa-libGLU-debuginfo
Any chance those could be added the the debuginfo repository? Without them gdb chokes before it gets to the SIGILL line.
Gordan
El 22/7/19 a las 18:53, Gordan Bobic escribió:
I'm still trying to hunt down where this SIGILL I'm hitting is coming from, and the next obstacle I've hit is some missing debuginfo packages, specifically: libGLEW-debuginfo libXau-debuginfo libXext-debuginfo mesa-libGLU-debuginfo
Any chance those could be added the the debuginfo repository? Without them gdb chokes before it gets to the SIGILL line.
Those were built during the first bootstrap, using the old plague server, and were never from there. You can find the original builds, along with debuginfo here https://armv7.dev.centos.org/repodir/c7-pass-1/
HTH, Pablo.
Gordan
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
glew there is version 1.9. The distro packages include 1.10. How did that happen?
On Mon, Jul 22, 2019 at 11:11 PM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
El 22/7/19 a las 18:53, Gordan Bobic escribió:
I'm still trying to hunt down where this SIGILL I'm hitting is coming from, and the next obstacle I've hit is some missing debuginfo packages, specifically: libGLEW-debuginfo libXau-debuginfo libXext-debuginfo mesa-libGLU-debuginfo
Any chance those could be added the the debuginfo repository? Without them gdb chokes before it gets to the SIGILL line.
Those were built during the first bootstrap, using the old plague server, and were never from there. You can find the original builds, along with debuginfo here https://armv7.dev.centos.org/repodir/c7-pass-1/
HTH, Pablo.
Gordan
Arm-dev mailing listArm-dev@centos.orghttps://lists.centos.org/mailman/listinfo/arm-dev
Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core.
Anyone got any other ideas?
On Tue, Jul 23, 2019 at 7:25 PM Gordan Bobic gordan@redsleeve.org wrote:
glew there is version 1.9. The distro packages include 1.10. How did that happen?
On Mon, Jul 22, 2019 at 11:11 PM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
El 22/7/19 a las 18:53, Gordan Bobic escribió:
I'm still trying to hunt down where this SIGILL I'm hitting is coming from, and the next obstacle I've hit is some missing debuginfo packages, specifically: libGLEW-debuginfo libXau-debuginfo libXext-debuginfo mesa-libGLU-debuginfo
Any chance those could be added the the debuginfo repository? Without them gdb chokes before it gets to the SIGILL line.
Those were built during the first bootstrap, using the old plague server, and were never from there. You can find the original builds, along with debuginfo here https://armv7.dev.centos.org/repodir/c7-pass-1/
HTH, Pablo.
Gordan
Arm-dev mailing listArm-dev@centos.orghttps://lists.centos.org/mailman/listinfo/arm-dev
El 23/7/19 a las 15:36, Gordan Bobic escribió:
Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core.
Anyone got any other ideas?
I've had some problems using stock gdb, so I generally use gdb from dts-7
On Tue, Jul 23, 2019 at 7:25 PM Gordan Bobic <gordan@redsleeve.org mailto:gordan@redsleeve.org> wrote:
glew there is version 1.9. The distro packages include 1.10. How did that happen? On Mon, Jul 22, 2019 at 11:11 PM Pablo Sebastián Greco <pablo@fliagreco.com.ar <mailto:pablo@fliagreco.com.ar>> wrote: El 22/7/19 a las 18:53, Gordan Bobic escribió:I'm still trying to hunt down where this SIGILL I'm hitting is coming from, and the next obstacle I've hit is some missing debuginfo packages, specifically: libGLEW-debuginfo libXau-debuginfo libXext-debuginfo mesa-libGLU-debuginfo Any chance those could be added the the debuginfo repository? Without them gdb chokes before it gets to the SIGILL line.Those were built during the first bootstrap, using the old plague server, and were never from there. You can find the original builds, along with debuginfo here https://armv7.dev.centos.org/repodir/c7-pass-1/ HTH, Pablo.Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org <mailto:Arm-dev@centos.org> https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, pablo@fliagreco.com.ar wrote:
El 23/7/19 a las 15:36, Gordan Bobic escribió:
Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core.
Anyone got any other ideas?
I've had some problems using stock gdb, so I generally use gdb from dts-7
My acronym-fu is weak. What is dts-7?
El 23/7/19 a las 17:41, Gordan Bobic escribió:
On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, <pablo@fliagreco.com.ar mailto:pablo@fliagreco.com.ar> wrote:
El 23/7/19 a las 15:36, Gordan Bobic escribió:Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core. Anyone got any other ideas?I've had some problems using stock gdb, so I generally use gdb from dts-7My acronym-fu is weak. What is dts-7?
That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can find the armhfp version here https://buildlogs.centos.org/c7-devtoolset-7.armhfp/
Pablo.
Hmm, after a lot of debuginfo chasing, rebuilding packages where I couldn't find them, different gdbs I have hit a dead end again. No missing debuginfos reported, SIGILL still happens, but backtrace says it can't read memory at address 0x2c. In step through mode, the last it comes up with is:
796 reshape(winWidth, winHeight); 798 event_loop(dpy, win);
and then it SIGILLs...
I never thought it would be so difficult to find out what library function is executing when SIGILL gets emitted. :-(
On Wed, Jul 24, 2019 at 11:42 AM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
El 23/7/19 a las 17:41, Gordan Bobic escribió:
On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, pablo@fliagreco.com.ar wrote:
El 23/7/19 a las 15:36, Gordan Bobic escribió:
Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core.
Anyone got any other ideas?
I've had some problems using stock gdb, so I generally use gdb from dts-7
My acronym-fu is weak. What is dts-7?
That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can find the armhfp version here https://buildlogs.centos.org/c7-devtoolset-7.armhfp/
Pablo.
Pablo, I don't suppose you (or anyone else here) has had any ideas on how to get any further in debugging this?
On Wed, Jul 31, 2019 at 10:21 PM Gordan Bobic gordan@redsleeve.org wrote:
Hmm, after a lot of debuginfo chasing, rebuilding packages where I couldn't find them, different gdbs I have hit a dead end again. No missing debuginfos reported, SIGILL still happens, but backtrace says it can't read memory at address 0x2c. In step through mode, the last it comes up with is:
796 reshape(winWidth, winHeight); 798 event_loop(dpy, win);
and then it SIGILLs...
I never thought it would be so difficult to find out what library function is executing when SIGILL gets emitted. :-(
On Wed, Jul 24, 2019 at 11:42 AM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
El 23/7/19 a las 17:41, Gordan Bobic escribió:
On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, pablo@fliagreco.com.ar wrote:
El 23/7/19 a las 15:36, Gordan Bobic escribió:
Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core.
Anyone got any other ideas?
I've had some problems using stock gdb, so I generally use gdb from dts-7
My acronym-fu is weak. What is dts-7?
That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can find the armhfp version here https://buildlogs.centos.org/c7-devtoolset-7.armhfp/
Pablo.
Gordan, sorry for the absence, I've been swamped with C8, and now with C7.7, not to mention $dayjob. I have no theories at the moment, and if I'd love to help once both versions are out.
Pablo.
El 8/8/19 a las 13:39, Gordan Bobic escribió:
Pablo, I don't suppose you (or anyone else here) has had any ideas on how to get any further in debugging this?
On Wed, Jul 31, 2019 at 10:21 PM Gordan Bobic <gordan@redsleeve.org mailto:gordan@redsleeve.org> wrote:
Hmm, after a lot of debuginfo chasing, rebuilding packages where I couldn't find them, different gdbs I have hit a dead end again. No missing debuginfos reported, SIGILL still happens, but backtrace says it can't read memory at address 0x2c. In step through mode, the last it comes up with is: 796 reshape(winWidth, winHeight); 798 event_loop(dpy, win); and then it SIGILLs... I never thought it would be so difficult to find out what library function is executing when SIGILL gets emitted. :-( On Wed, Jul 24, 2019 at 11:42 AM Pablo Sebastián Greco <pablo@fliagreco.com.ar <mailto:pablo@fliagreco.com.ar>> wrote: El 23/7/19 a las 17:41, Gordan Bobic escribió:On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, <pablo@fliagreco.com.ar <mailto:pablo@fliagreco.com.ar>> wrote: El 23/7/19 a las 15:36, Gordan Bobic escribió:Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core. Anyone got any other ideas?I've had some problems using stock gdb, so I generally use gdb from dts-7 My acronym-fu is weak. What is dts-7?That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can find the armhfp version here https://buildlogs.centos.org/c7-devtoolset-7.armhfp/ Pablo.
Another debuginfo package missing: mesa-private-llvm-3.9.1-3.el7.armv7hl
On Thu, Aug 8, 2019 at 5:50 PM Pablo Sebastián Greco pablo@fliagreco.com.ar wrote:
Gordan, sorry for the absence, I've been swamped with C8, and now with C7.7, not to mention $dayjob. I have no theories at the moment, and if I'd love to help once both versions are out.
Pablo. El 8/8/19 a las 13:39, Gordan Bobic escribió:
Pablo, I don't suppose you (or anyone else here) has had any ideas on how to get any further in debugging this?
On Wed, Jul 31, 2019 at 10:21 PM Gordan Bobic gordan@redsleeve.org wrote:
Hmm, after a lot of debuginfo chasing, rebuilding packages where I couldn't find them, different gdbs I have hit a dead end again. No missing debuginfos reported, SIGILL still happens, but backtrace says it can't read memory at address 0x2c. In step through mode, the last it comes up with is:
796 reshape(winWidth, winHeight); 798 event_loop(dpy, win);
and then it SIGILLs...
I never thought it would be so difficult to find out what library function is executing when SIGILL gets emitted. :-(
On Wed, Jul 24, 2019 at 11:42 AM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
El 23/7/19 a las 17:41, Gordan Bobic escribió:
On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, < pablo@fliagreco.com.ar> wrote:
El 23/7/19 a las 15:36, Gordan Bobic escribió:
Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core.
Anyone got any other ideas?
I've had some problems using stock gdb, so I generally use gdb from dts-7
My acronym-fu is weak. What is dts-7?
That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can find the armhfp version here https://buildlogs.centos.org/c7-devtoolset-7.armhfp/
Pablo.
Yeap, another one that wasn't migrated from the old buildsystem, https://armv7.dev.centos.org/repodir/c71708-pass-1/mesa-private-llvm/3.9.1-3...
Pablo.
El 8/8/19 a las 17:19, Gordan Bobic escribió:
Another debuginfo package missing: mesa-private-llvm-3.9.1-3.el7.armv7hl
On Thu, Aug 8, 2019 at 5:50 PM Pablo Sebastián Greco <pablo@fliagreco.com.ar mailto:pablo@fliagreco.com.ar> wrote:
Gordan, sorry for the absence, I've been swamped with C8, and now with C7.7, not to mention $dayjob. I have no theories at the moment, and if I'd love to help once both versions are out. Pablo. El 8/8/19 a las 13:39, Gordan Bobic escribió:Pablo, I don't suppose you (or anyone else here) has had any ideas on how to get any further in debugging this? On Wed, Jul 31, 2019 at 10:21 PM Gordan Bobic <gordan@redsleeve.org <mailto:gordan@redsleeve.org>> wrote: Hmm, after a lot of debuginfo chasing, rebuilding packages where I couldn't find them, different gdbs I have hit a dead end again. No missing debuginfos reported, SIGILL still happens, but backtrace says it can't read memory at address 0x2c. In step through mode, the last it comes up with is: 796 reshape(winWidth, winHeight); 798 event_loop(dpy, win); and then it SIGILLs... I never thought it would be so difficult to find out what library function is executing when SIGILL gets emitted. :-( On Wed, Jul 24, 2019 at 11:42 AM Pablo Sebastián Greco <pablo@fliagreco.com.ar <mailto:pablo@fliagreco.com.ar>> wrote: El 23/7/19 a las 17:41, Gordan Bobic escribió:On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, <pablo@fliagreco.com.ar <mailto:pablo@fliagreco.com.ar>> wrote: El 23/7/19 a las 15:36, Gordan Bobic escribió:Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core. Anyone got any other ideas?I've had some problems using stock gdb, so I generally use gdb from dts-7 My acronym-fu is weak. What is dts-7?That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can find the armhfp version here https://buildlogs.centos.org/c7-devtoolset-7.armhfp/ Pablo.
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
Would it be a good time to perhaps either do a full rebuild of everything into a unified repository? Or at least merge the old build repository with the main public repository? I can't be the first one to run into this, even if I am the first one to mention it here.
On Thu, Aug 8, 2019 at 10:03 PM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
Yeap, another one that wasn't migrated from the old buildsystem,
https://armv7.dev.centos.org/repodir/c71708-pass-1/mesa-private-llvm/3.9.1-3...
Pablo. El 8/8/19 a las 17:19, Gordan Bobic escribió:
Another debuginfo package missing: mesa-private-llvm-3.9.1-3.el7.armv7hl
On Thu, Aug 8, 2019 at 5:50 PM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
Gordan, sorry for the absence, I've been swamped with C8, and now with C7.7, not to mention $dayjob. I have no theories at the moment, and if I'd love to help once both versions are out.
Pablo. El 8/8/19 a las 13:39, Gordan Bobic escribió:
Pablo, I don't suppose you (or anyone else here) has had any ideas on how to get any further in debugging this?
On Wed, Jul 31, 2019 at 10:21 PM Gordan Bobic gordan@redsleeve.org wrote:
Hmm, after a lot of debuginfo chasing, rebuilding packages where I couldn't find them, different gdbs I have hit a dead end again. No missing debuginfos reported, SIGILL still happens, but backtrace says it can't read memory at address 0x2c. In step through mode, the last it comes up with is:
796 reshape(winWidth, winHeight); 798 event_loop(dpy, win);
and then it SIGILLs...
I never thought it would be so difficult to find out what library function is executing when SIGILL gets emitted. :-(
On Wed, Jul 24, 2019 at 11:42 AM Pablo Sebastián Greco < pablo@fliagreco.com.ar> wrote:
El 23/7/19 a las 17:41, Gordan Bobic escribió:
On Tue, 23 Jul 2019, 21:35 Pablo Sebastián Greco, < pablo@fliagreco.com.ar> wrote:
El 23/7/19 a las 15:36, Gordan Bobic escribió:
Joy. So missing / mismatching debuginfo warnings are now all resolved, but execution through gdb fails eventually with "Cannot access memory at address ..." gdb/frame.c:445: internal-error: get_frame_id: Assertion `fi->this_id.p' failed. And gdb helpfully offers to dump core.
Anyone got any other ideas?
I've had some problems using stock gdb, so I generally use gdb from dts-7
My acronym-fu is weak. What is dts-7?
That is devtoolset-7 (basically gcc 7.x, gdb 8.x and others. you can find the armhfp version here https://buildlogs.centos.org/c7-devtoolset-7.armhfp/
Pablo.
Arm-dev mailing listArm-dev@centos.orghttps://lists.centos.org/mailman/listinfo/arm-dev
El 23/7/19 a las 15:25, Gordan Bobic escribió:
glew there is version 1.9. The distro packages include 1.10. How did that happen?
That was my bad, I got all the versions from the same place, and glew was updated, I'll upload 1.10 shortly.
On Mon, Jul 22, 2019 at 11:11 PM Pablo Sebastián Greco <pablo@fliagreco.com.ar mailto:pablo@fliagreco.com.ar> wrote:
El 22/7/19 a las 18:53, Gordan Bobic escribió:I'm still trying to hunt down where this SIGILL I'm hitting is coming from, and the next obstacle I've hit is some missing debuginfo packages, specifically: libGLEW-debuginfo libXau-debuginfo libXext-debuginfo mesa-libGLU-debuginfo Any chance those could be added the the debuginfo repository? Without them gdb chokes before it gets to the SIGILL line.Those were built during the first bootstrap, using the old plague server, and were never from there. You can find the original builds, along with debuginfo here https://armv7.dev.centos.org/repodir/c7-pass-1/ HTH, Pablo.Gordan _______________________________________________ Arm-dev mailing list Arm-dev@centos.org <mailto:Arm-dev@centos.org> https://lists.centos.org/mailman/listinfo/arm-dev
Arm-dev mailing list Arm-dev@centos.org https://lists.centos.org/mailman/listinfo/arm-dev
-
Gordan Bobic -
Pablo Sebastián Greco