Skip to main content
A
Anonymous
March 21, 2011
Question

Assert failed in /server/js/jsClient.cpp

  • March 21, 2011
  • 1 reply
  • 607 views

Hi!

Last week I started getting errors like these:

2011-03-21      02:09:38        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

2011-03-21      02:09:38        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1174      -

2011-03-21      02:22:55        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

2011-03-21      02:22:55        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1174      -

2011-03-21      02:24:28        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

2011-03-21      02:24:28        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1174      -

2011-03-21      02:25:25        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

2011-03-21      02:25:25        10725   (e)2581279      Assert failed in /server/js/jsClient.cpp line 1174      -

We've never seen these errors before, but since last week they started pop up every now and then. We haven't changed anything at all, neither JS nor auth modules or anything else. We're running FMIS 3.5.5.

What could this be?

Thanks!

    This topic has been closed for replies.

    1 reply

    S
    SE_0208
    Participating Frequently
    March 22, 2011

    Is there any specific scenario which causes this asserts? Say like when particualr application is running or when load reaches so much or something like that?

    A
    Anonymous
    March 22, 2011

    Hi,

    haven't been able to identify anything specific. We only have a single application running, which have not changed. The only change I could come to think of is in the player client swf, but the only change regarding server communcations is that we've started using the smart seek feature. However I cannot correlate any use of smart seek to the log entrys..

    The load has been relatively low.

    Now, while looking a bit closer at the log from one of our server, since the 17th (the first occurence of this error), I think I found a pattern..

    Looking at the log entries so far today:

    2011-03-22      00:26:10        2673    (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

    2011-03-22      00:27:28        2673    (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

    2011-03-22      00:28:12        2673    (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

    2011-03-22      00:29:09        2673    (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

    2011-03-22      00:30:12        2673    (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

    2011-03-22      00:33:03        2673    (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

    2011-03-22      00:35:26        2673    (e)2581279      Assert failed in /server/js/jsClient.cpp line 1172      -

    Correlating that with a log from our auth plugin, which logs the events it is processing, I found that some E_CONNECT matches perfectly:

    [adapter 2011-03-22 00:26:09 07] [0xf6495858] E_CONNECT for 6289926047628424050 (111.222.111.222) with UA

    [adapter 2011-03-22 00:27:27 07] [0xf6495858] E_CONNECT for 6516229511323743601 (111.222.111.222) with UA

    [adapter 2011-03-22 00:28:12 06] [0xf6495858] E_CONNECT for 3695286375975647088 (111.222.111.222) with UA

    [adapter 2011-03-22 00:29:08 19] [0xf6495858] E_CONNECT for 5942272346862549616 (111.222.111.222) with UA

    [adapter 2011-03-22 00:30:11 19] [0xf6495858] E_CONNECT for 8156377800847012208 (111.222.111.222) with UA

    [adapter 2011-03-22 00:33:02 08] [0xf6495858] E_CONNECT for 7809865668313888368 (111.222.111.222) with UA

    [adapter 2011-03-22 00:35:25 22] [0xf6495858] E_CONNECT for 8167957891804707183 (111.222.111.222) with UA


    The thing with this one is, there is no UA string. Going back to a few days back, the same pattern can be seen.. A client connects without a UA, and the JS assert shows up. Normally it should say somehting like "with UA WIN 10,2,152,26"..
    So, I'd say it is related to a blank UA string.. but, why would a UA string be blank?

    Terms & ConditionsAccessibility statement
    Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices