Bug #928
closedETV: Use of uninitialized value $line in subtraction (-)
Added by Evgeny Novikov over 13 years ago. Updated over 13 years ago.
0%
Description
Some stupid bug indeed.
Files
| current--X--commands-xml--X--defaultshadows--X--32_7.pax (800 KB) current--X--commands-xml--X--defaultshadows--X--32_7.pax | Evgeny Novikov, 03/11/2011 01:12 PM |
Updated by Evgeny Novikov over 13 years ago
The problem comes from macro expansion as I understand. So for macro MAGIC_CHECK(q->int_ops->magic, MAGIC_QTYPE_OPS); from videobuf-core.c (see temporary link for example) blast or/and cil produces following error trace:
Location: id=721#2 src="/home/tester/ldv/workdir/envs/1/work/work-3e1f2356ce231488dc1fa844e5ce91bcb59fc2a1/drivers/media/video/au0828/au0828-video.c/work/current--X--commands.xml--X--defaultshadows--X--32_7/artificial_env_1/csd_deg_dscv/23/dscv_tempdir/dscv/ri/32_7/drivers/media/video/videobuf-core.c"; line=1062
Block(mem_15@videobuf_read_stream = * (q@videobuf_read_stream ).int_ops;)
Location: id=721#3 src=""; line=-1
Pred(* (mem_15@videobuf_read_stream ).magic == 304484355)
Location: id=721#5 src=""; line=-1
Block(__cil_tmp25@videobuf_read_stream = 0;)
Negative lines numbers line=-1 confuse error trace visualizer. Of course I'll fix it in ETV, but the problem isn't in it indeed.
Updated by Evgeny Novikov over 13 years ago
- Status changed from Open to Resolved
- Published in build set to f64e542
The minor fix to ETV was done and it's tested now (f64e542). Pavel, please, investigate the problem described above (close this bug and open a new one if so).
Updated by Evgeny Novikov over 13 years ago
- Status changed from Resolved to Closed
We discuss with Pavel it isn't a thing to be focused in cil and blast. If somebody won't like absence of links to macro (note that link for first instruction of macro is printed well) we may use previous src:line instead of "":-1.
Updated by Pavel Shved over 13 years ago
- Status changed from Closed to Open
Reopening bug.
When ETV encounters "line=-1", it prints an empty line to the list of the files required for this trace. This, in turn, confuses ldv-core-reporter, and it doesn't print any <sourcefile> tags to this trace because of that empty line.
I think, both ETV and ldv-core-reporter should be fixed: the former should not print the empty line, and the latter should be more tolerant. To make a double protection, you know.
Updated by Pavel Shved over 13 years ago
A quick way to reproduce bug:
ldv-manager rule_models=32_7 "envs=linux-2.6.37.tar.bz2" drivers=drivers/serial/serial_core.ko kernel_driver=1
Updated by Pavel Shved over 13 years ago
The fix for ldv-task-reporter is pushed to master (54fae52).
Updated by Pavel Shved over 13 years ago
If a launch has undergone such issue (i.e. you see after uploading the "No <sourcefile> tag found"), it's not all lost! Check out the latest master, and do the following.
1. Install the new toolset.
2. Find in the log you saved (did you?) for the launch the line "LDV_ENVS_TARGET.*ldv-task-reporter" (LDV_DEBUG>=30 is required). Run it in the working dir you ran ldv-manager from. My command (for the test driver above) looks like this:
LDV_ENVS_TARGET=/home/pavel/work/ldv/test/inst/current /home/pavel/tmp/ldv/ldv/ldv-task-reporter --report-name=report_after_ldv_core.xml --report-out=/home/pavel/work/ldv/test/work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7/report_after_ldv.xml --state-file=/home/pavel/work/ldv/test/work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7/ldv.state --reports-dir=/home/pavel/work/ldv/test/work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7This command takes a considerable time to finish, so don't panic if it runs for a long time!
3. Find the "report-fixup" command in your log. Run it, and the "package" command on the line below:
/home/pavel/tmp/ldv/ldv-manager/report-fixup work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7/report_after_ldv.xml current drivers/serial/serial_core.ko kernel work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7/report_after_ldv.xml.source/ work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7 >work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7/tmp/current--X--drivers-serial-serial_core-ko--X--rrrrlinux-2.6.31.6--X--32_7.report.xml /home/pavel/tmp/ldv/ldv-manager/package work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7/tmp/current--X--drivers-serial-serial_core-ko--X--rrrrlinux-2.6.31.6--X--32_7.report.xml finished/current--X--drivers-serial-serial_core-ko--X--rrrrlinux-2.6.31.6--X--32_7.pax -s '|^work/current--X--drivers/serial/serial_core.ko--X--rrrrlinux-2.6.31.6--X--32_7/tmp\/*||'
Now you've got a brand new PAX with the sources attached properly.
Updated by Evgeny Novikov over 13 years ago
- Status changed from Open to Resolved
Now ETV uses a previously obtained source code file and line number instead of "":-1 (5d00c3c).
Updated by Evgeny Novikov over 13 years ago
- Status changed from Resolved to Closed
Pavel's solution of the given problem to fix large tasks perfectly works! I'll try not to make such small breaking everything fixes as that I've done.