Unsound behavior with -rte option in Magnesium - frama-c

I am facing an incoherent behavior with the -rte option in Magnesium version (installed directly from ubuntu). I am wondering if someone is aware of that problem or if I am doing something wrong.
I have a program with an incorrect acces outside an array. When lauching frama-c-gui with no options and value analysis, the out-of-bounds access is detected and the corresponding annotation is displayed with an orange circle. When using the -rte option, two annotations are displayed (for the lower and upper bound of the array), and a green circle is displayed for both (which is incorrect).
/*# assert rte: index_bound: 0 ≤ cpt; */
/*# assert rte: index_bound: cpt < 5; */
The console says :
tableau_erreur.c:11:[value] Assertion 'rte,index_bound' got status valid.
I suspect there is a mismatch between the two annotations because they both have the same "name" : index_bound.
Also, the part of code after the loop containing the faulty access is colored in red, suggesting that the analysis correctly inferred that it is not reachable because of an error before.
Here is my program :
int main(){
int t[5] = {1,2,3,4,5};
int cpt =0 ;
int tmp ;
while (cpt<10){
tmp = getchar() ;
if ( t[cpt] > tmp )
{ return 1 ; }
cpt++ ;
}
return 10 ;
}
Here is a capture of my display (using frama-c-gui -rte tableau_erreur.c).
When I do not use the -rte option the result is correct (orange circle) :
I had a look at the bug tracker but did not find trace of that. I did not manage to compile a more recent version of Frama-C to test it.

Update: this behavior has been fixed in the Silicon release of Frama-C (the status associated to assertion rte: index_bound: cpt < 5 remains unknown).
I couldn't reproduce exactly what you said, but after launching the GUI as in your command, then clicking on the "Run" button in the Value analysis panel, I got the green bullets.
This is equivalent to running frama-c-gui -rte -then -val, which also displays the green (incorrect) bullets.
Indeed this seems to be an issue even in the current Frama-C version, so a bug report is in order. Note that manually inserting an equivalent annotation (//# assert cpt < 5;) does result in an yellow bullet, as expected. Also, unrolling the loop (with -slevel 5, for instance) also results in an yellow bullet. The issue seems to be related specifically to the usage of the RTE plug-in, but in any case it will be investigated.
On a side note, the index_bound label next to the property is not an identifier, just a label, hence not unique, and unrelated to the issue here.
Technical details: Frama-C has notions of properties and statuses, which are summarized by the bullets next to the source code, but described in more detail either through the Properties panel (you may need to modify some filters and click on the Refresh button to see them) or the Report plug-in (e.g. frama-c -val -then -report). In your example, the first iteration of the loop has a value of cpt that is 0, therefore the property acquires a valid status (green bullet), and in the last iteration (when cpt is 5) it gets a unknown status (yellow bullet). For some reason it was (incorrectly) consolidated as valid, hence the green bullet. The Value log does however display file.c:8:[value] warning: assertion 'rte,index_bound' got status unknown, which shows up in the Messages panel in the GUI. This does not explain the error, but the combination of both Messages and Properties panels is a powerful tool to diagnose issues with properties.

Related

Plothraw PARIGP (or similar) doesn't work (latexit crash)

I'm a new user of PARI/GP, and after writing my script, I wanted to make a graph of it. As my function take an integer and return a number, it's closer to a sequence. Actually, I didn't know how to do it, so I read the documentation of PARI/GP, and after that I made some test in order to obtain a graph from a list.
After reading an answer in stackoverflow (Plotting multiple lists in Pari), I wanted to test with the following code:
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 0);
But when I do it, it tries to open something on latexit, but then it crash and give me a problem report.
I didn't even know that I had an app named latextit, maybe it was install during the installation of PARI/GP. Anyway, how can I fix this?
PARI/GP definitely doesn't install latexit.
The way hi-res graphics work on the Win32 version of PARI/GP is to write down an Enhanced Metafile (.EMF) in a temp directory and ask the system to
"open" it. When you installed latexit it probably created an association in the registry to let it open .EMF files
i3Pi does not mean what you think, it just creates a new variable with that name. You want i * 3 * Pi instead.
The following constructions both work in my setup
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 0);
plothraw([0..200], apply(i->cos(i*3*Pi/200), [0..200]), 1);
(the second one being more readable because a red line is drawn between successive points; I have trouble seeing the few tiny blue dots)
Instead of apply, you can use a direct constructor as in
vector(201, i, cos((i-1) * 3 * Pi / 200))
which of course can be computed more efficiently as
real( powers(exp(3*I*Pi/200), 200) )
(of course, it doesn't matter here, but compare both commands at precision \p10000 or so ...)

Xcos throws "Undefined variable: scifunc_block_m" message in console

When I run a Xcos model containing a scifunc_block_m block like shown below
I get an error message relating to data dimensions inconsistency:
"Data dimensions are inconsistent:"
" Variable size=[1,1]"
"Block output size=[100,1]."
But when I double click in the block in order to see what can I change to make the dimensions correct I get a message in the console saying
Undefined variable: scifunc_block_m
What bugs me is that scifunc_block_m is not the name of any variable, but rather the name of the block itself like can be seen in the official docs.
Of course I double checked that nowhere in my function phase_shifter neither anywhere else I have any variable named like that.
I tried with Scilab 6.1.1 and 6.1.0 believing that it might be a bug from apparently not.
In your phase_shifter.sce file generating the input variable,
the signalIn variable does not comply with the From Workspace block requirements, whose documentation says that the input variable
must be a structure with time and values fields
.time must be a column vector, and in your case
.values must also be a column
So,
t = (0:1/fs:Npp/fs - 1/fs); // time vector
signalIn = A*%e^(%i*w*t);
should be replaced with
t = (0:1/fs:Npp/fs - 1/fs)'; // time column vector
signalIn = struct("time",t, "values",A*%e^(%i*w*t));
This fixes the inconsistent dimensions message.
In addition, i am not able to reproduce your issue about Undefined variable: scifunc_block_m. The parameters interface opens as expected.
You may get this kind of messages if you try to run some xcos parts out of xcos, without beforehand loading xcos-related libraries.
Then, we get an unclear "Output should be of complex type." message on the From workspace block.
By the way, you try to plot some complex values. Please have a look to the MATMAGPHI block before entering MUX: https://help.scilab.org/docs/6.1.1/en_US/MATMAGPHI.html

Robot Framework: How to sort by

I have a webpage with a combobox to sort a list by Price, Name,... The list is in many pages, so I need to get all elements first and after, I will sort by and check if the elements are correct. Right?
I am trying to do it and navigate for all pages and get all elements. But it is only taking the elements in first page. I am totally new in Robot framework.
Does anyone have a suggestion how I can do it?
${name_list_actual} Create List
${cnt_pages}= Get Element Count //div[#class='container index-new-p']/div/nav[#class='text-center']/ul/li/*
Log To Console ${cnt_pages}
:FOR ${n} IN RANGE 1 ${cnt_pages}
\ Click link //div[#class='container index-new-p']/div/nav/ul/li[${n}]/a
\ ${cnt}= Get Element Count //*[#class="title"]/*
:FOR ${i} IN RANGE 1 ${cnt}
\ ${get_names} Get Element Attribute //table[#class='result-table']/tbody/tr[${i}]/td/div/div[2]/div/a text
\ Append To List ${name_list_actual} ${get_names}
${get_names}= Select All From List //table[#class='result-table']/tbody/tr[${i}]/td/div/div[2]/div/a
\ Log To Console ${name_list_actual}
\ Continue For Loop
Thanks so much
First and foremost, by your code sample's indent it looks like you're doing nested for loops - an outer one for the changing the pages, and an inner that'll get the text in each row. The thing is - Robot Framework doesn't support nested for loops - see the documentation.
What happened on execution is the first loop (the pagination) ran with just two statements and finished:
\ Click link //div[#class='container index-new-p']/div/nav/ul/li[${n}]/a
\ ${cnt}= Get Element Count //*[#class="title"]/*
Then all the rest were executed as part of the second.
A solution would be to have a keyword "Get All Values In The Table" that'll hold the inner loop, and call it in the current outer, which will paginate.
Another issue - you're using IN RANGE, passing 1 as start and ${cnt} as end; if it had value of 4, you probably expect the tracking variable to get all values from 1 to 4.
Yet range works with the first argument inclusive, and up to - but not getting to - the second argument; thus it covers the range 1 to 3. To salvage that, you'd need to set the upper bound to cnt+1, e.g. ${cnt + 1}.
Minor stuff:
You have a statement that's within the loop block, but not prefixed with \:
${get_names}= Select All From List //table[#class='result-table']/tbody/tr[${i}]/td/div/div[2]/div/a
I'm surprised it didn't give you a syntax error - it effectively breaks the loop, and the framework should complain the next lines are prefixed as if in a loop, but one is not started.
-
When you are changing the pages by the click, you are not making sure the UI has loaded the data for the new page. If this happens through ajax calls, you may very well be working with the previous page's data, thinking it is the new one - the selenium click returns control very fast, and the operands for getting the text are running - while the UI still waits for the new data and is displaying the previous one.
-
In RF version 3.1 the loop syntax is different - the block members are not prefixed with \, and it's closed with an END statement.
I'd suggest to migrate to it - a) the current one is going to be eventually deprecated, and b) in the new one the nesting would have been marked as syntax error (you're starting a new loop without END-ing the running one), instead of silently passing with unexpected behavior.

Qt error is printed on the console; how to see where it originates from?

I'm getting this on the console in a QML app:
QFont::setPointSizeF: Point size <= 0 (0.000000), must be greater than 0
The app is not crashing so I can't use the debugger to get a backtrace for the exception. How do I see where the error originates from?
If you know the function the warning occurs in (in this case, QFont::setPointSizeF()), you can put a breakpoint there. Following the stack trace will lead you to the code that calls that function.
If the warning doesn't include the name of the function and you have the source code available, use git grep with part of the warning to get an idea of where it comes from. This approach can be a bit of trial and error, as the code may span more than one line, etc, and so you might have to try different parts of the string.
If the warning doesn't include the name of the function, you don't have the source code available and/or you don't like the previous approach, use the QT_MESSAGE_PATTERN environment variable:
QT_MESSAGE_PATTERN="%{function}: %{message}"
For the full list of variables at your disposal, see the qSetMessagePattern() docs:
%{appname} - QCoreApplication::applicationName()
%{category} - Logging category
%{file} - Path to source file
%{function} - Function
%{line} - Line in source file
%{message} - The actual message
%{pid} - QCoreApplication::applicationPid()
%{threadid} - The system-wide ID of current thread (if it can be obtained)
%{qthreadptr} - A pointer to the current QThread (result of QThread::currentThread())
%{type} - "debug", "warning", "critical" or "fatal"
%{time process} - time of the message, in seconds since the process started (the token "process" is literal)
%{time boot} - the time of the message, in seconds since the system boot if that can be determined (the token "boot" is literal). If the time since boot could not be obtained, the output is indeterminate (see QElapsedTimer::msecsSinceReference()).
%{time [format]} - system time when the message occurred, formatted by passing the format to QDateTime::toString(). If the format is not specified, the format of Qt::ISODate is used.
%{backtrace [depth=N] [separator="..."]} - A backtrace with the number of frames specified by the optional depth parameter (defaults to 5), and separated by the optional separator parameter (defaults to "|"). This expansion is available only on some platforms (currently only platfoms using glibc). Names are only known for exported functions. If you want to see the name of every function in your application, use QMAKE_LFLAGS += -rdynamic. When reading backtraces, take into account that frames might be missing due to inlining or tail call optimization.
On an unrelated note, the %{time [format]} placeholder is quite useful to quickly "profile" code by qDebug()ing before and after it.
I think you can use qInstallMessageHandler (Qt5) or qInstallMsgHandler (Qt4) to specify a callback which will intercept all qDebug() / qInfo() / etc. messages (example code is in the link). Then you can just add a breakpoint in this callback function and get a nice callstack.
Aside from the obvious, searching your code for calls to setPointSize[F], you can try the following depending on your environment (which you didn't disclose):
If you have the debugging symbols of the Qt libs installed and are using a decent debugger, you can set a conditional breakpoint on the first line in QFont::setPointSizeF() with the condition set to pointSize <= 0. Even if conditional breakpoints don't work you should still be able to set one and step through every call until you've found the culprit.
On Linux there's the tool ltrace which displays all calls of a binary into shared libs, and I suppose there's something similar in the M$ VS toolbox. You can grep the output for calls to setPointSize directly, but of course this won't work for calls within the lib itself (which I guess could be the case when it handles the QML internally).

PyQt5 QTableView cell editing behaviour - superimposition of original value

I'm messing around with tables in PyQt for the first time and am running into some unexpected behaviour when editing cell values.
Specifically when I type data, it appears over the top of the existing cell data (so if the cell originally had '123' in it, and I type '456', I end up with 2 lots of 3 characters, one over the top of the other - at least until I press enter).
Just to be clear, I have no issues with setData writing the changes to the model, or with the changes being reflected in the table after editing is complete - that's all happening fine. The only problem is seeing the original value and the new value I'm typing in occupying the same space until editing finishes.
So presumably what I want to do is alter my existing data method:
def data(self, index, int_role=None):
row = index.row()
column = index.column()
if int_role == QtCore.Qt.DisplayRole:
return str(self._data[row][column])
elif int_role == QtCore.Qt.EditRole:
return str(self._data[row][column])
else:
return None
so that it somehow recognizes if the cell it's being asked to provide data for (in DisplayRole mode) is currently being edited, and if so, return an empty string instead of the actual data (as the EditRole branch of the code is being called as well at the same time and is happily handling display duties until editing is finished).
I've had a look around the QT docs but cannot work out how to do this.
Edit: After ceppo's comments, I've looked at creating a new ItemDelegate - but looking into it further it looked like I would be able to instead switch out the itemEditorFactory in the existing one - specifically I added the following to my code:
newEditor = QLineEdit()
newEditor.setAutoFillBackground(True)
ief = QItemEditorFactory()
ief.registerEditor(QVariant.String, LineEditorCreator())
tableView.itemDelegate().setItemEditorFactory(ief)
with LineEditorCreator defined as follows:
class LineEditCreator(QItemEditorCreatorBase):
def __init__(self):
QItemEditorCreatorBase.__init__(self)
def createWidget(self, parent):
wdgt = QLineEdit(parent)
wdgt.setAutoFillBackground(True)
return wdgt
def valuePropertyName(self):
return "String"
however now I get a Segmentation fault as soon as I try to edit a cell value. Putting a print statement in as the first line in the createWidget statement shows it not ever getting executing - some print statements in the createWidget shows that the Segmentation faults occur even before the first line of createWidget executes (though the __ init __ method completes fine).
Ceppo also said that the behaviour I'm experiencing could be due to a bug (in Qt, PyQt or something else underlying) - I'll be replacing my current Ubuntu 15.10 installation with 16.04 soon so with some luck that will solve the issue entirely.
Upgrading ubuntu 15.10 to 16.04 did indeed fix the problem.
My 16.04 distro has python3-pyqt5 and other qt packages with versions all around 5.5.1 - I did check but didn't think to jot down the versions of those packages in my 15.10 installation before wiping it - but packages.ubuntu.com says 5.4.2 is the current version for 15.10 and that sounds familiar.
So if anyone else with QT 5.4.2 is running into the same thing, upgrading to 5.5.1 might be worth a try - either by upgrading to a newer distro or attempting to find and use a backport of the newer QT version.
Thanks Ceppo93, it was a good guess.

Resources