Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 10 14:41
    Snaipe commented #336
  • Jan 10 09:11
    Bensuperpc closed #335
  • Jan 10 09:10
    Bensuperpc commented #335
  • Jan 10 07:58
    hydrapolic commented #336
  • Jan 10 06:51
    kugel- commented #336
  • Jan 10 05:56
    Snaipe commented #333
  • Jan 09 23:55
    Snaipe commented #223
  • Jan 09 23:52
    Snaipe commented #335
  • Jan 09 23:45
    hydrapolic commented #336
  • Jan 09 23:44
    hydrapolic commented #337
  • Jan 09 23:31
    Snaipe closed #337
  • Jan 09 23:29

    Snaipe on bleeding

    api: fixed zero producing warni… (compare)

  • Jan 09 23:29
    Snaipe closed #330
  • Jan 09 23:28
    Snaipe commented #333
  • Jan 09 23:25
    Snaipe commented #336
  • Jan 09 23:23

    Snaipe on bleeding

    meson: Add/fix options to not-b… (compare)

  • Jan 09 23:23
    Snaipe closed #334
  • Jan 09 23:23
    Snaipe commented #334
  • Jan 09 23:21
    Snaipe commented #337
  • Jan 09 22:26
    hydrapolic opened #337
Dominik
@kaidowei
No it's not.
Test running normal
Franklin Mathieu
@Snaipe
This is weird then
does this happen occasionnally, or is it consistently visible?
Actually, nevermind -- I didn't fully remember how the timeout was implemented
I'll come up with a fix soon
Dominik
@kaidowei
@Snaipe a coworker found another interesting thing
[====] Running 6 tests from confparse_complex:
[RUN ] confparse_complex::confcopy_ar7cfg
[RUN ] confparse_complex::confcopy_ifaceconfig
[ERR ] Could not link back the event PID to the active workers.
[ERR ] The event pipe might have been corrupted.
only occurs with -jX (X>1) with cr_assert_file_contents_eq_str()
and not always, but with about 50% chance
currently, we do not have a minimal working example, but I can test for you
the function that provokes the error:
static void verify_complex_config(struct ar7cfg **cfg)
{
    OUTSTREAM *os;
    FILE *fexpected;

    static char saved[8<<20];

    cr_assert_not_null(saved);
    os = outstream_mem(saved, sizeof(saved));
    cr_assert_not_null(os);

    /* Update the tests whenever the defaults in ar7cfg.tab change */
    ASSERT_EQUAL((*cfg)->mode, dsldmode_router);
    ASSERT_STRING_EQUAL((*cfg)->active_provider, "tonline");
    ASSERT_EQUAL((*cfg)->mtu_cutback, 1500);

    config_varsave_topsection_ostream(AR7CFG_ar7cfg_struct, os, (void **)cfg, AR7CFG_ar7cfg_struct->offset, 0);

    fexpected = fopen("expected", "r");

    //~ cr_assert(!feof(fexpected) && !ferror(fexpected));
    cr_assert_file_contents_eq_str(fexpected, saved);

    fclose(fexpected);
    outstream_close(os);
}
Franklin Mathieu
@Snaipe
Might be the result of an out of bounds -- I would gladly accept the example so I can get myself to debug
Dominik
@kaidowei
as I said, no working minimal example...
sorry, can't reproduce it without our complete code...
Dominik
@kaidowei
Update:
if we call cr_file_match_str everything works fine, but the macro seems to cause the problem
when we use cr_assert_file_contents_neq_strinstead of cr_assert_file_contents_eq_strthe string parameter is cropped
in the resulting error message
and the 8<<20 is not a problem. Even if we malloc the buffer, criterion still fails
Franklin Mathieu
@Snaipe
It seems very similar to the out of bounds I fixed for 2.2.1 -- it's possible that this is related and that I missed the issue.
Dominik
@kaidowei
we should think about a bug hunting bounty program ;)
Franklin Mathieu
@Snaipe
I can only pay in coffee at the moment though :D
But yeah, these bugs are the result of me rushing 2.0
Rushing a release never does well for a project.
Dominik
@kaidowei
tell me about it... our PM is rushing all the time :p
Dominik
@kaidowei
it's okay, we have coffee here too :)
update: if we provide a custom message for the assert, there is no problem (seems reasonable)
maybe there is a problem with the pipe and (very long) strings
he says without the send_event there is no problem
Franklin Mathieu
@Snaipe
right
I think that since saved is passed through the pipe with the default message
it just tries to handle it and dies
or rather than dying, corrupts the pipe
Dominik
@kaidowei
a bit strange, that this only happens in 50% of the cases
Franklin Mathieu
@Snaipe
it really depends on the state of the pipe tbh
if the pipe is almost full and you try to push 8 << 20 bytes down its throat, it might lead to this particular problem
which is probably why you can't reproduce it in a minimal example, there needs to be other tests run in parallel that push data down the pipe
this is all supposition though, I'll have to make some tests on my end
I'm curious if this would happen with the I/O rewrite on bleeding, though
Dominik
@kaidowei
...
good idea with the multiple tests
Dominik
@kaidowei
does that "work" for you too=
Franklin Mathieu
@Snaipe
Can't really run this right now, I'll tell you when I get a bit more time
I assume that the issue disappears when you reduce the side of saved?
Dominik
@kaidowei
yeah and sorry, you need a file with a looong string in "testfile"
Franklin Mathieu
@Snaipe
er, buf
Dominik
@kaidowei
let me check
yes
reducing the buf size and the file content helps
Franklin Mathieu
@Snaipe
file contents shouldn't really matter (other than speeding up the test), because the file name is passed rather than the full blown contents