Bug #972
openIncomplete error trace sources for input/evdev.c
0%
Description
error-trace-visualizer does not provide hyper links for some of lines of an error trace for input/evdev.c.
Also I can see the following warning in Error trace visualizer log:
error-trace-visualizer: WARNING: Source code file '="";' wasn't processed. Use a previosly obtained value 'workdir/envs/1/work/work-99759619b27662d1290901228d77a293e6e83200/drivers/input/evdev.c/work/current--X--commands.xml--X--defaultshadows--X--32_7--X--68_1--X--RCU_1/artificial_env_1/csd_deg_dscv/12/dscv_tempdir/dscv/ri/RCU_1/drivers/input/evdev.c.p' for a given source code file.
How can I get more details regarding the issues?
Updated by Pavel Shved over 13 years ago
- Category set to Infrastructure
- Assignee set to Evgeny Novikov
Alexey Khoroshilov wrote:
error-trace-visualizer does not provide hyper links for some of lines of an error trace for input/evdev.c.
...
How can I get more details regarding the issues?
A good place to start would be showing the lines that cause problems. You may also check bug #928 and bug #930. Line numbers are not attached to some lines (macros and CIL's "simeplemem" are known to cause problems), but ETV makes its best effort to do at least something.
Updated by Alexey Khoroshilov over 13 years ago
Pavel Shved wrote:
A good place to start would be showing the lines that cause problems.
Here they are:
1936 - blast_must_tmp__9493 =&(llvm_cbe_handler_addr);
llvm_cbe_handler_addr = llvm_cbe_handler;
blast_must_tmp__9494 =&(llvm_cbe___mptr);
blast_must_tmp__9495 =&(llvm_cbe___mptr1);
blast_must_tmp__9496 =&(llvm_cbe_retval2);
blast_must_tmp__9497 = &(llvm_cbe_dev);
1940 blast_must_tmp__9498 = mutex_lock_interruptible_nested(&(input_mutex), 0) { /* The function body is undefined. */ };
1941 - llvm_cbe_retval2 = blast_must_tmp__9498;
blast_must_tmp__9499 = llvm_cbe_retval2;
1941 assert(blast_must_tmp__9499 == 0);
1944 blast_must_tmp__9501 = llvm_cbe_handler_addr;
1944 - INIT_LIST_HEAD18290(blast_must_tmp__9501 field11 /* llvm_cbe_list */);
... lines with hyper links...
384 - blast_must_tmp__7189 =&(llvm_cbe_handle_addr);
llvm_cbe_handle_addr = llvm_cbe_handle;
blast_must_tmp__7190 =&(llvm_cbe_type_addr);
llvm_cbe_type_addr = llvm_cbe_type;
blast_must_tmp__7191 =&(llvm_cbe_code_addr);
llvm_cbe_code_addr = llvm_cbe_code;
blast_must_tmp__7192 =&(llvm_cbe_value_addr);
llvm_cbe_value_addr = llvm_cbe_value;
blast_must_tmp__7193 =&(llvm_cbe___dummy2);
blast_must_tmp__7194 =&(llvm_cbe___dummy);
blast_must_tmp__7195 =&(llvm_cbe_flags);
blast_must_tmp__7196 = &(llvm_cbe_grab);
blast_must_tmp__7197 = &(llvm_cbe_dev);
blast_must_tmp__7198 = llvm_cbe_handle_addr;
blast_must_tmp__7199 =* (blast_must_tmp__7198 ).field3;
llvm_cbe_dev = blast_must_tmp__7199;
blast_must_tmp__7200 = llvm_cbe_dev;
blast_must_tmp__7201 = llvm_cbe_type_addr;
390 - blast_must_tmp__7202 = is_event_supported(blast_must_tmp__7201 /* llvm_cbe_code */, * (blast_must_tmp__7200 ).field5offset 0 /* llvm_cbe_bm */, 31 /* llvm_cbe_max */);
{
61 - blast_must_tmp__6941 =&(llvm_cbe_code_addr);
llvm_cbe_code_addr = llvm_cbe_code;
blast_must_tmp__6942 =&(llvm_cbe_bm_addr);
llvm_cbe_bm_addr = llvm_cbe_bm;
blast_must_tmp__6943 =&(llvm_cbe_max_addr);
llvm_cbe_max_addr = llvm_cbe_max;
blast_must_tmp__6944 = llvm_cbe_code_addr;
blast_must_tmp__6945 = llvm_cbe_max_addr;
63 assert(blast_must_tmp__6944 <= blast_must_tmp__6945);
63 - blast_must_tmp__6946 = llvm_cbe_bm_addr;
blast_must_tmp__6947 = llvm_cbe_code_addr;
63 - blast_must_tmp__6948 = variable_test_bit18269(blast_must_tmp__6947 /* llvm_cbe_nr */, blast_must_tmp__6946 /* llvm_cbe_addr */);
... lines with hyper links...
Updated by Evgeny Novikov over 13 years ago
If you put your mouse over lines that haven't link you will see an advice, ETV will show you a source code file name where it tried to link. For the given example it links to input.c.p although there isn't such the file at the right side (where source code files are shown).
Updated by Evgeny Novikov over 13 years ago
The given log messages clarifies the situation a bit:
ldv-task-reporter: WARNING: Can't find kernel file '/home/tester/ldv/workdir/envs/1/work/work-99759619b27662d1290901228d77a293e6e83200/drivers/hwmon/lis3lv02d.c/work/current--X--commands.xml--X--defaultshadows--X--32_7--X--68_1--X--RCU_1/artificial_env_1/csd_deg_dscv/15/dscv_tempdir/dscv/ri/RCU_1/drivers/input/input.c.p'. Skipping this file.
while the caught file is placed in completely another directory (drivers/input instead of drivers/hwmon):
'/home/tester/ldv/workdir/envs/1/work/work-99759619b27662d1290901228d77a293e6e83200/drivers/input/evdev.c/work/current--X--commands.xml--X--defaultshadows--X--32_7--X--68_1--X--RCU_1/artificial_env_1/csd_deg_dscv/12/dscv_tempdir/dscv/ri/RCU_1/drivers/input/evdev.c.p'
May be this affects the given issue. The last can be associated with RI caching as usual or with some auto cleaning or so on.
Updated by Evgeny Novikov over 13 years ago
- Status changed from New to Feedback
Wait for additional feedback. Temporaries should be kept and investigated (if there is such the file indeed).
Updated by Evgeny Novikov over 13 years ago
Pavel Shved wrote:
Caching?..
RI caching can miss input.c.p file by some reason.
Updated by Evgeny Novikov over 13 years ago
- Status changed from Feedback to Open
I investigated a detailed log supposed by Alexey for the given driver and found that the problem is associated with RI caching kept for old tasks.
In fact RI caching works, all required files are in a cache and are successfully obtained from it. Although it isn't enough for error trace visualization since cached object files link to source code files having absolute paths like:
/home/tester/ldv/workdir/envs/1/work/work-99759619b27662d1290901228d77a293e6e83200/drivers/hwmon/lis3lv02d.c/work/current--X--commands.xml--X--defaultshadows--X--32_7--X--68_1--X--RCU_1/artificial_env_1/csd_deg_dscv/15/dscv_tempdir/dscv/ri/RCU_1/drivers/input/input.c.p
but after input.c.p is obtained from the cache it is placed to a completely another place:
/home/tester/ldv/workdir/envs/1/work/work-99759619b27662d1290901228d77a293e6e83200/drivers/input/evdev.c/work/current--X--commands.xml--X--defaultshadows--X--RCU_1/artificial_env_1/csd_deg_dscv/12/dscv_tempdir/dscv/ri/RCU_1/drivers/input/input.c.p
For linked object files there isn't such the problem because of corresponding paths are substituted but for source code files there isn't such simple ability (I believe that we won't modify object files internals).
Another approach is to match paths partially. For instance, consider just:
dscv_tempdir/dscv/ri/RCU_1/drivers/input/input.c.p
or even:
drivers/input/input.c.p
and copy a corresponding found file. Further it is most likely that error trace visualizer will do all in the correct manner since it already compares truncated names.