Add FileHandle tests #5895

maciejbocianski · 2018-01-22T14:52:40Z

Description

This PR contains Mbed retargeting systems tests for C library FILE functions

Status

IN DEVELOPMENT

Migrations

NO

Related PRs

#5714

maciejbocianski · 2018-01-22T14:55:56Z

@kjbracey-arm I wrote some retargeting tests as you proposed in #5714, feel free to review.

I noticed some inconsistencies between fwrite function implementation among GCC/ARM/IAR stdlibs. When try to write more elements then possible (code under define PARTIAL_WRITE) expected behaviour is to write as many elements as possible and return number of elements written successfully. But ARM and IAR return 0 in this situation - no elements written (while actually some elements was written in retarget layer)

kjbracey · 2018-01-23T08:20:59Z

I think there may be a retargeting bug in partial write that you're revealing. I corrected something there in #5571, at least for ARMCC.

write(0) shouldn't return -EAGAIN - 0 is more conventional.

Also, you really shouldn't be returning EAGAIN anyway, as you've not been asked to be non-blocking. Basically the C library retarget doesn't really support non-blocking files - it's not clear how those calls should work in response to EAGAIN. They might just immediately retry like they would for EINTR.

And as for partial writes, fwrite isn't allowed to report a partial writes except in the case of a real error. And EAGAIN (or EINTR) aren't "real" errors - there could be special code to hide them in the retargetting.

I would say you should probably return something more definite indicating you're off the end of the file - EFBIG or something? It's a partial write because you actually can't write more and have hit a real error, not just some transient condition.

Having done that, after that's been returned, you should be able to check ferror(FILE) is set and that errno is set to EFBIG. Don't forget to rewind() to clear the error condition. (fseek(0,SET) doesn't).

kjbracey · 2018-01-23T08:33:07Z

TESTS/mbed_platform/FileHandle/TestFile.h

+                if(SEEK_POS_IS_VALID(offset)) {
+                    _pos = offset;
+                } else {
+                    return -1;


This should return a specific error code. -EINVAL, I believe.

kjbracey · 2018-01-23T08:35:03Z

TESTS/mbed_platform/FileHandle/TestFile.h

+                ((uint8_t*)buffer)[read] = _data[_pos++];
+            } else {
+                if(0 == read) {
+                    read = -EAGAIN;


If you're trying to act like a normal file, you should return 0 if _pos >= end of file (on entry). As in my previous comment, -EAGAIN is never appropriate for a blocking file.

If you want to test error returns, I'd have some sort of other "set_error" back door control to make it do that instead of the normal operation.

Maybe you could mark a particular byte somewhere in the file invalid, so if (_pos == _error_pos) indicate EIO sort of thing, distinct from the "end of file". Dunno.

kjbracey · 2018-01-23T08:36:07Z

TESTS/mbed_platform/FileHandle/TestFile.h

+        _fnCalled = fnRead;
+
+        if(0 == size) {
+            return -EAGAIN;


0 is normal, so you don't need to special-case.

kjbracey · 2018-01-23T08:38:56Z

TESTS/mbed_platform/FileHandle/TestFile.h

+            case SEEK_CUR:
+            {
+                const int32_t new_pos = _pos + offset;
+                if(SEEK_POS_IS_VALID(new_pos)) {


You're repeating yourself here - switch statement could just work out new_pos, leaving the "is valid" stuff common afterwards.

maciejbocianski · 2018-01-23T11:15:42Z

test was updated (according suggestions)

kjbracey · 2018-01-23T12:22:59Z

TESTS/mbed_platform/FileHandle/TestFile.h

+            if(NEW_POS_IS_VALID(_pos)) {
+                _data[_pos++] = ((uint8_t*)buffer)[written];
+            } else {
+                break;


I don't think this works for write - it's not symmetrical with read. You can't just stop writing data and start returning 0 - there's no "end of file" when writing. Not sure what the C libraries will do if you do this.

While in theory you can do what you like with a FileHandle (or POSIX file descriptor), the C library will be assuming somewhat conventional file-like behaviour, and that doesn't include just not making progress. The C library may well keep continuously recalling you until you return an error code, or the total amount had been written.

You will need a specific error code like -ENOSPC here to indicate that they're writing beyond the capacity, and to make sure the C library gives up.

So I think it's return 0 if size == 0, return the amount actually written if you had to stop due to lack of space, and return -ENOSPC if can't write anything due to lack of space.

kjbracey · 2018-01-23T12:26:43Z

TESTS/mbed_platform/FileHandle/main.cpp

+
+using utest::v1::Case;
+
+//#define PARTIAL_WRITE


So, what would it take to get this on? Do we need any tweaks from #5571? IIRC, _write() for ARMCC is currently broken because it returns size - written, even when written is actually an error code.

Maybe we might want to split this into testing EOF for read, and actual errors on read/write. Those are key things that are easy to screw up, and critically important for a minority of users. So I think need to be in this test.

(Seen that in networking - very often TCP glue code can't do end-of-stream properly, which is fine for many users, but utterly breaks certain protocols).

Firstly, maybe I should start testing with changes from #5571?
Is there any sens of testing old (buggy) version while there is new one around the corner?
When it's expected to be ready for merge?

As far as I recall there was only that 1 intended adjustment to _write, but maybe you could just try merging with #5571 and cross-checking results.

At the present it's not clear whether there's a test error, retarget error or C library error.

I think you do need to lock the test down to be specifically testing EOF (read) and error (read or write), as those are the only "partial" returns I would expect the C library to handle. I haven't quite fully gone through to understand what the partial code is testing at present.

Other partial returns like non-blocking or special devices are needed, but they would require someone to be accessing the FileHandle directly (or using POSIX read/write from #5571) - I wouldn't expect to be able to do that through the C library stdio.

If you have ifdeffed out bits that are failing - I'd like us to understand why, and I'd especially want to know if #5571 still doesn't fix them.

Ideally I'd like this to go in with just a few ifdeffed things that we know #5571 will fix (adjusting #5571 if necessary).

Sure, the ifdefs are temporarily.
Regarding write/read problem we have two scenarios:

write more than file can handle - error occurs, we expects:
a. fwrite should return number of objects written successfully
b. fwrite set error state (checked then with ferror) when not all objects were written

read more than file contain - EOF occurs
a. fread should return number of objects read successfully
b. fread set EOF when no more objects to read

I did some test on top of #5571 and get following results:

Complete mbed_retarget FileHandle rework #5571 only fixes a bit IAR write behaviour (eliminates infinite write loop when write more than file can handle)

Described scenarios are fulfilled only on GCC_ARM compiler

ARM compiler results
o scenario (1) ❌ fwrite sets error, and return 0 instead of number of objects written successfully
o scenario (2) ✅ fread sets EOF and return number of objects read successfully

IAR compiler results
o scenario (1) ❌ fwrite sets error, and return 3 instead of number of objects written successfully (5 to write, written 2, returned 3)
o scenario (2) ✅ fread sets eof and return number of objects read successfully

To sum up, looks like both ARM and IAR fwrite implementation is broken

Thanks, you're a star! Will study and ponder.

Okay, that does appear to be straightforward C library bugs. Don't think we could successfully work around those.

For ARM C, we are clearly returning the number of characters not written, as the documentation requires: "A positive number representing the number of characters not written (so any nonzero return value denotes a failure of some sort)."

The ARM C library detects this is an error as expected, but somehow doesn't pass back the correct return value. And because it doesn't make a final re-call like GCC, we won't get errno set either. But setting errno isn't strictly required by fwrite/fputc. Just the return value, and setting the ferror flag. Return value is at least a clear failure indication to app - just a bit pessimistic about where it failed.

As for IAR, um what's it doing? Can you check with some different numbers? I'd guess it's doing "successful+1" or maybe it's doing "requested-successful"? Either way, apps are in danger of false success reports (if error on last byte or first byte, respectively).

Checked the IAR docs/reference implementation, and we're doing the right thing. Doubt we could do anything to influence its behaviour, if it's calling us 1 byte at a time. Not sure why it's doing that. It's even going 1 step further and making that "0" call after every byte. According to comments in their write.c, (NULL,0) is a flush request - we should be presumably be calling sync on that. Although if it's going to do it on every byte, maybe not?

I guess they're attempting to couple fflush/nonbuffered and fsync(), but there's supposed to be a difference- fflush() flushes C library to system, and fsync() flushes system to disk. The first isn't supposed to imply the second.

Is the weird 1-at-a-time IAR behaviour maybe something to do with what mbed_set_unbuffered_stream does? I was assuming that was a bug workaround. What if you call setbuf(file, NULL) instead?

IAR with std::setbuf(file, NULL) instead mbed_set_unbuffered_stream(file) behaves more reasonably
log2.txt

Weird. I actually have no idea what that IAR-specific code is supposed to achieve. It was introduced here: 9909e7c

The setvbuf call there should be equivalent to setbuf(NULL), but apparently isn't. Not sure what the rest of the commit affecting the behaviour of Stream is.

Turns out some explanation is on GitHub, not the commit message: #770

Is the bug now fixed, so that can be removed? What version of IAR are you testing with?

0xc0170 · 2018-01-30T14:17:01Z

@maciejbocianski I would like to understand the dependency on 5571 and master. Does it feel like 5571 should get these tests in 5571 (being part of it), that would test the changes there. Or would this be good to have tested on master (reading through the comments here there are some issues with C libs?)
Please advice

kjbracey · 2018-01-30T14:26:00Z

This is testing existing functionality, so it's useful to make sure #5571 isn't breaking anything.

We've identified a couple of things that #5571 fixes, but there are things that are apparently faulty both before and after #5571.

Could merge this PR first with some tests excluded until #5571 lands, then we could add a commit to #5571 to enable the tests it fixes.

Then continue to investigate the pre-existing and continuing oddities.

0xc0170 · 2018-01-30T15:21:01Z

Could merge this PR first with some tests excluded until #5571 lands, then we could add a commit to #5571 to enable the tests it fixes.

Then continue to investigate the pre-existing and continuing oddities.

@kjbracey-arm thanks for the proposal, sounds good to me (first master)

@maciejbocianski if you agree, lets make this ready for master and identify what does not work (and 5571 will fix)

kjbracey · 2018-02-01T09:02:57Z

I propose we disable the fwrite tests for now, or at least relax the condition to check that error is detected - ferror set, return value less than expected. Get this merged to test #5571, then continue investigation.

maciejbocianski · 2018-02-01T09:14:49Z

@kjbracey-arm @0xc0170
Test was updated, now it fits IAR/ARM/GCC_ARM stdlib diversification

@kjbracey-arm due to some problem with VPN couldn't fully check it with ARMCC/IAR on top of #5571

0xc0170 · 2018-02-01T09:53:31Z

/morph build

mbed-ci · 2018-02-01T10:10:38Z

Build : SUCCESS

Build number : 1036
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5895/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

mbed-ci · 2018-02-01T11:56:15Z

Exporter Build : SUCCESS

Build number : 716
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5895/

mbed-ci · 2018-02-01T12:27:07Z

Test : SUCCESS

Build number : 843
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5895/843

kjbracey

If you're leaving IAR disabled, at each point I would find it useful to note in a comment what behaviour actually does exhibit at the moment.

kjbracey · 2018-02-01T12:16:26Z

TESTS/mbed_platform/FileHandle/main.cpp

+    file = fdopen(&fh, "w+");
+    TEST_ASSERT_NOT_NULL(file);
+#ifdef __ICCARM__
+    std::setbuf(file, NULL); // fix IAR every byte sync


Well, this then wouldn't need an ifdef. mbed_set_unbuffered_stream just calls std::setbuf(file, NULL) if not ICCARM.

You mean in #5571 ? On master there is still std::setvbuf(_file,buf,_IONBF,NULL);

If I'm not confused, this expands to

#ifdef __ICC_ARM__ setbuf(file, NULL); #else // mbed_set_unbuffered_stream(file): #if defined (__ICCARM__) char buf[2]; setvbuf(file,buf,_IONBF,NULL); #else setbuf(file, NULL); #endif #endif

Which, more consisely is

setbuf(file, NULL);

Now get it:) My idea was to preserve mbed_set_unbuffered_stream(file); line to show that this function should be fixed by #5571 or in the future

So truncate it to single line setbuf(file, NULL); ?

I think so - the set_unbuffered_stream (and mbed_gets and mbed_getc) are just some sort of IAR workaround for the normal functions setbuf gets and getc at some point not working properly - a few bits of code like Stream knew to call them instead. If we are currently thinking setbuf is working, just use it and drop the workaround.

kjbracey · 2018-02-01T12:19:07Z

TESTS/mbed_platform/FileHandle/main.cpp

+    ret = std::fputc(char_buf[0], file);
+    TEST_ASSERT_TRUE(TestFile<FS>::functionCalled(TestFile<FS>::fnWrite));
+    TEST_ASSERT_TRUE(std::ferror(file) > 0);
+    std::clearerr(file); // for ARMCC


You keep calling fseek(file, 0, SEEK_SET). If you called rewind() instead, that would clear the error. Should be necessary on every compiler

kjbracey · 2018-02-01T12:19:47Z

TESTS/mbed_platform/FileHandle/main.cpp

+    TestFile<FS>::resetFunctionCallHistory();
+    ret = std::fputc(char_buf[0], file);
+    TEST_ASSERT_TRUE(TestFile<FS>::functionCalled(TestFile<FS>::fnWrite));
+    TEST_ASSERT_TRUE(std::ferror(file) > 0);


!= 0 (explicit or implied) - it isn't specified as returning positive.

kjbracey · 2018-02-01T12:20:42Z

TESTS/mbed_platform/FileHandle/main.cpp

+    TestFile<FS>::resetFunctionCallHistory();
+    ret = std::fgetc(file);
+#ifndef __ICCARM__
+    // IAR optimize reads


Is this the thing that the IAR unbuffered thing was working around, so it now behaves wrongly? Or does it break either way?

It just behaves differently than other, but we could normalize read part and only test the first read against retargeting layer read call and remove code from ifdefs

Is it making a single read(N) call rather than multiple read(1)? So it must be buffering? Which is what I think the original #770 was working around.

I would say that is invalid behaviour, but may not be too fatal if read(N) doesn't actually wait for N characters, but returns just what it has. The #770 fix may have been prompted by Stream::read(N) doing that wrongly.

That kind of makes sense. Serial::read(N) waits for N characters, so Serial::scanf would have jammed. But the built-in stdin "read" always waited for 1 and returned 1, so scanf would have worked.

UARTSerial::read(N) now works correctly, returning 1-N bytes as soon as it has anything.

Maybe the set_unbuffered_stream workaround is only really needed when running against a TTY FileHandle with broken read().

If I'm not wrong they read 512B at first 'fread' call. Can't check this now due to disabled VPN:(

kjbracey · 2018-02-01T12:21:20Z

TESTS/mbed_platform/FileHandle/main.cpp

+    TestFile<FS>::resetFunctionCallHistory();
+    ret = std::fgetc(file);
+    TEST_ASSERT_TRUE(TestFile<FS>::functionCalled(TestFile<FS>::fnRead));
+    TEST_ASSERT_TRUE(std::feof(file) > 0);


Again, non-zero. Not specified as positive.

TTornblom · 2018-02-01T12:44:38Z

What IAR EW version is used for the tests?

Is there a project I can use for testing/debugging the (incorrect) fwrite behavior in IAR EW?

maciejbocianski · 2018-02-01T12:51:27Z

IAR EW for ARM: 7.80.4.12495
IAR EW shared components: 7.5.6.4719

TTornblom · 2018-02-01T13:12:03Z

Thanks.

7.80 is old and there are no updates planned.

Has this been tested with IAR EW 8.x?

Are you using the standard libraries as shipped from IAR, or has there been any modification to them?

maciejbocianski · 2018-02-01T13:31:33Z

Has this been tested with IAR EW 8.x?

not yet

Are you using the standard libraries as shipped from IAR, or has there been any modification to them?

use standard without modification

TTornblom · 2018-02-01T13:55:42Z

Any project available, IAR EW 7.80 or 8, that shows the misbehaving fwrite so that we may test it to make sure we don't have a problem in EW 8?

maciejbocianski · 2018-02-01T14:04:44Z

main.cpp with test will be enought?
will prepare one

TTornblom · 2018-02-01T14:37:01Z

Preferably something that can be imported into IAR EWARM and run there, on the simulator or real HW.

Thanks.

maciejbocianski · 2018-02-02T14:31:36Z

@TTornblom Code for testing
https://gist.github.com/maciejbocianski/56b0ffcf7cc3b91b928801bd7d8f93c9

Also prepared repo with generated project files
clone https://github.com/maciejbocianski/mbed-os-example-blinky.git
checkout iar_stream_test branch

TTornblom · 2018-02-06T11:22:56Z

I have been looking into the IAR fwrite() loop issue and in the test code I received I notice that write() returns -ENOSPC (-28), which is returned to fflushOne(), which called from fflush(). fflushOne() only accepts _LLIO_ERROR (-1) or 0 as error return from write(), so returning -ENOSPC (-28) is not a valid return value.

From http://pubs.opengroup.org/onlinepubs/9699919799/functions/write.html:

RETURN VALUE
Upon successful completion, these functions shall return the number of bytes actually written to the file associated with fildes. This number shall never be greater than nbyte. Otherwise, -1 shall be returned and errno set to indicate the error.

If you return -1 instead of -ENOSPC the test will not loop.

kjbracey · 2018-02-06T13:03:20Z

I believe that problem occurs on master, but has already been fixed on #5571 - FileHandle::write will return -ENOSPC, but write and __write return -1.

On current master FileHandle::write returns -ENOSPC, and that does get passed straight back as the return value from __write. :(

So, which of the tests still fail with #5571?

0xc0170 · 2018-02-06T13:13:34Z

So, which of the tests still fail with #5571?

@maciejbocianski #5571 is ready, waiting for the tests !

maciejbocianski · 2018-02-06T13:29:29Z

The test should pass also with #5571, failing cases are turned off per compiler by ifdefs

0xc0170 · 2018-02-06T16:05:37Z

/morph build

mbed-ci · 2018-02-06T16:25:17Z

Build : SUCCESS

Build number : 1073
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/5895/

Triggering tests

/morph test
/morph uvisor-test
/morph export-build

mbed-ci · 2018-02-06T18:11:51Z

Test : SUCCESS

Build number : 881
Test logs :http://mbed-os-logs.s3-website-us-west-1.amazonaws.com/?prefix=logs/5895/881

mbed-ci · 2018-02-06T18:20:02Z

Exporter Build : SUCCESS

Build number : 751
Build artifacts/logs : http://mbed-os.s3-website-eu-west-1.amazonaws.com/?prefix=builds/exporter/5895/

0xc0170 · 2018-02-07T09:19:15Z

The test should pass also with #5571, failing cases are turned off per compiler by ifdefs

@kjbracey-arm Happy with this going to master, and addressing issues that were found separately? I imagine this goes in, 5571 retested with master + this PR . Then we can focus on outstanding issues with the tests.

kjbracey · 2018-02-07T09:20:17Z

Yes.

maciejbocianski · 2018-02-07T12:19:59Z

I believe that problem occurs on master, but has already been fixed on #5571 - FileHandle::write will return -ENOSPC, but write and __write return -1.

On current master FileHandle::write returns -ENOSPC, and that does get passed straight back as the return value from __write. :(

Tested on top of #5571 and the problem with infinite loop is not present

So, which of the tests still fail with #5571?

There is still problem with fwrite return value when not all data was written.
e.g. when we try to write 3 bytes and mbed retargeting layer return 2 (two bytes written) then this value is not returned by fwrite but 0 is returned

kjbracey · 2018-02-07T12:31:08Z

0 is returned

ARM C does the same thing. I'd say fwrite returning something >= 0 and < requested is sufficient to pass. I can't think of a real use case for knowing the exact number - applications will just stop noting failure when they see < requested.

Didn't we have a case where it was returning "actual + 1" or "requested - number"? Those would be problematic.

TTornblom · 2018-02-07T15:43:56Z

Ok, I thought the issue was that fwrite would loop during the test.

I have verified that fwrite does indeed return 0 when it fails writing all the data, even if it has written some of it.

I will file a bug for this.

If returning 0 in this case is acceptable, I will give it a low priority.

kjbracey · 2018-02-08T09:37:52Z

I believe we did have some worse problems though, if you read back up the comments. Streams being buffered even when they shouldn't have been, and weird behaviour if the #770 "use a 2-byte buffer" workaround for that is active. @maciejbocianski can hopefully re-summarise.

TTornblom · 2018-02-08T11:45:12Z

I have added a comment to #770.

If there are still problems with this, please elaborate and I will look into it.

cmonr requested a review from kjbracey January 22, 2018 21:55

cmonr added the needs: review label Jan 22, 2018

kjbracey mentioned this pull request Jan 23, 2018

Complete mbed_retarget FileHandle rework #5571

Merged

kjbracey reviewed Jan 23, 2018

View reviewed changes

maciejbocianski force-pushed the fileHandle_tests branch from 5c12c5b to 17bc9b6 Compare January 23, 2018 11:07

kjbracey reviewed Jan 23, 2018

View reviewed changes

maciejbocianski force-pushed the fileHandle_tests branch from 17bc9b6 to 87897dc Compare January 23, 2018 13:44

cmonr added needs: work and removed needs: review labels Jan 25, 2018

maciejbocianski force-pushed the fileHandle_tests branch from 87897dc to 55a78c8 Compare February 1, 2018 09:10

0xc0170 added needs: review and removed needs: work labels Feb 1, 2018

kjbracey reviewed Feb 1, 2018

View reviewed changes

maciejbocianski force-pushed the fileHandle_tests branch from 55a78c8 to a1f2482 Compare February 1, 2018 12:55

maciejbocianski force-pushed the fileHandle_tests branch from a1f2482 to 4ec4ea4 Compare February 1, 2018 13:24

maciejbocianski force-pushed the fileHandle_tests branch from 4ec4ea4 to b196332 Compare February 1, 2018 14:29

Add FileHandle tests

8e1cfe2

maciejbocianski force-pushed the fileHandle_tests branch from b196332 to 8e1cfe2 Compare February 2, 2018 13:57

0xc0170 added ready for merge release-version: 5.7.5 and removed needs: review labels Feb 7, 2018

0xc0170 merged commit 1d759d0 into ARMmbed:master Feb 7, 2018

cmonr removed the ready for merge label Feb 8, 2018

maciejbocianski mentioned this pull request Feb 23, 2018

platform: FileHandle test - remove optimization for stdlib diversity #6182

Merged

4 tasks

Add FileHandle tests #5895

Add FileHandle tests #5895

Uh oh!

Conversation

maciejbocianski commented Jan 22, 2018

Description

Status

Migrations

Related PRs

Uh oh!

maciejbocianski commented Jan 22, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kjbracey commented Jan 23, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kjbracey Jan 23, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maciejbocianski commented Jan 23, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maciejbocianski Jan 26, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

0xc0170 commented Jan 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kjbracey commented Jan 30, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xc0170 commented Jan 30, 2018

Uh oh!

kjbracey commented Feb 1, 2018

Uh oh!

maciejbocianski commented Feb 1, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

0xc0170 commented Feb 1, 2018

Uh oh!

mbed-ci commented Feb 1, 2018

Triggering tests

Uh oh!

mbed-ci commented Feb 1, 2018

Uh oh!

mbed-ci commented Feb 1, 2018

Uh oh!

kjbracey left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

maciejbocianski commented Jan 22, 2018 •

edited

Loading

kjbracey Jan 23, 2018 •

edited

Loading

maciejbocianski Jan 26, 2018 •

edited

Loading

0xc0170 commented Jan 30, 2018 •

edited

Loading

kjbracey commented Jan 30, 2018 •

edited

Loading

maciejbocianski commented Feb 1, 2018 •

edited

Loading

maciejbocianski Feb 1, 2018 •

edited

Loading