|
From: Mike W. <mik...@ve...> - 2007-05-28 18:56:20
|
>> The illegal instruction appears to be: >> >> 1003be34: fc 00 08 1e fctiwz f0,f1 >> ==1402== Illegal opcode at address 0x4265A690 >> ==1402== at 0x1003BE34: BS_Scheduler::BS_Scheduler(BS_Manager*, >fctiwz is definitely implemented - you can't do much FP computation >on a PowerPC without it. Are you sure you have the right instruction? >From the stack trace you sent I'd guess the instruction is at >0x4265A690. Unfortunately that means it's in a shared library and >will be harder to track down with objdump. I believe you are right about the shared library. Do you have any suggestions on how to find the offending symbol? I am trying to rebuild my project with only static libraries, but it is a large and byzantine code base I am not overly familiar with. |
|
From: Julian S. <js...@ac...> - 2007-05-28 19:05:42
|
> I believe you are right about the shared library. Do you have any > suggestions on how to find the offending symbol? Here's what I do. You need to figure out which shared library it is in and the text segment offset. Here is an example. Suppose V complains that the illegal opcode is at 0x4627124. I rerun with -v, and get a lot of lines like this --23824-- Reading syms from /usr/lib/libXext.so.6.4.0 (0x40D2000) --23824-- object doesn't have a symbol table --23824-- Reading syms from /usr/lib/libXt.so.6.0.0 (0x40E1000) --23824-- object doesn't have a symbol table --23824-- Reading syms from /usr/lib/libX11.so.6.2.0 (0x4131000) --23824-- object doesn't have a symbol table Find the one which has the highest address whilst still being less than 0x4627124. In this case it is --23824-- Reading syms from /usr/lib/libXrender.so.1.3.0 (0x4626000) --23824-- object doesn't have a symbol table So now you know that (1) the relevant library is /usr/lib/libXrender.so.1.3.0 (2) the text segment offset is 0x1124 (== 0x4627124 - 0x4626000) So now objdump -d /usr/lib/libXrender.so.1.3.0 and look at the insn listed at 0x1124. This sometimes (often, even), works, but sometimes not. YMMV. J |
|
From: Mike W. <mik...@ve...> - 2007-05-29 20:22:35
|
Julian Seward wrote: >> I believe you are right about the shared library. Do you have any >> suggestions on how to find the offending symbol? >> > > Here's what I do. You need to figure out which shared library it is in > and the text segment offset. Here is an example. Suppose V complains > that the illegal opcode is at 0x4627124. I rerun with -v, and get a > lot of lines like this > > --23824-- Reading syms from /usr/lib/libXext.so.6.4.0 (0x40D2000) > --23824-- object doesn't have a symbol table > --23824-- Reading syms from /usr/lib/libXt.so.6.0.0 (0x40E1000) > --23824-- object doesn't have a symbol table > --23824-- Reading syms from /usr/lib/libX11.so.6.2.0 (0x4131000) > --23824-- object doesn't have a symbol table > > [...] > > This sometimes (often, even), works, but sometimes not. YMMV. > > > Thanks for the suggestion. Unfortunately, the address where the illegal instruction is occurring is nowhere near any of the library addresses, and it looks like it's actually on the heap somewhere, according to /proc/$pid/maps. Is the core file Valgrind generates of any use in this situation? |
|
From: Julian S. <js...@ac...> - 2007-05-29 22:22:12
|
> Thanks for the suggestion. Unfortunately, the address where the illegal > instruction is occurring is nowhere near any of the library addresses, > and it looks like it's actually on the heap somewhere, according to > /proc/$pid/maps. Is the core file Valgrind generates of any use in this > situation? I just remembered, when Valgrind's powerpc instruction decoder hits an instruction it doesn't like, it prints some stuff about the primary and secondary opcode and what the instruction actually is. Do you have that info? But in any case .. if you think that V is executing in the middle of the heap, maybe your program did a bogus jump? If so, that tends to be symptomatic of type confusion in C++ code -- often in very obscure ways to do with inheritance. J |
|
From: Mike W. <mik...@ve...> - 2007-05-30 20:13:29
|
Julian Seward wrote: >> Thanks for the suggestion. Unfortunately, the address where the illegal >> instruction is occurring is nowhere near any of the library addresses, >> and it looks like it's actually on the heap somewhere, according to >> /proc/$pid/maps. Is the core file Valgrind generates of any use in this >> situation? >> > > I just remembered, when Valgrind's powerpc instruction decoder hits > an instruction it doesn't like, it prints some stuff about the > primary and secondary opcode and what the instruction actually is. > Do you have that info? > > I didn't see anything in the logs along those lines, even with -v. Is there a way to force Valgrind to do so? |