Project

General

Profile

Actions

Bug #928

closed

ETV: Use of uninitialized value $line in subtraction (-)

Added by Evgeny Novikov over 13 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Category:
Infrastructure
Start date:
03/11/2011
Due date:
% Done:

0%

Estimated time:
Detected in build:
svn
Platform:
Published in build:
f64e542

Description

Some stupid bug indeed.


Files

Actions #1

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.

Actions #2

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).

Actions #3

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.

Actions #4

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.

Actions #5

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
Actions #6

Updated by Pavel Shved over 13 years ago

The fix for ldv-task-reporter is pushed to master (54fae52).

Actions #7

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_7
This 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.

Actions #8

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).

Actions #9

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.

Actions

Also available in: Atom PDF