Sur d’autres sites (6866)

• Fatal error detected by JRE : libavcodec involved

  16 novembre 2015, par hdf

  I’m experiencing this issue whenever I’m trying to run my java program. Could someone give me a clues on how to fix it ?

  EDIT : the issue only occurs after a new environment has been set up.

  #
  
  # A fatal error has been detected by the Java Runtime Environment:
  
  #
  
  # 
  
  #
  
  # JRE version: OpenJDK Runtime Environment (7.0_85-b01) (build 1.7.0_85-b01)
  
  # Java VM: OpenJDK 64-Bit Server VM (24.85-b03 mixed mode linux-amd64 compressed oops)
  
  # Derivative: IcedTea 2.6.1
  
  # Distribution: Ubuntu 14.04 LTS, package 7u85-2.6.1-5ubuntu0.14.04.1
  
  # Problematic frame:
  
  # C  [libavcodec.so.52.123.0+0x442060]
  
  #
  
  # Failed to write core dump. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
  
  #
  
  # If you would like to submit a bug report, please include
  
  # instructions on how to reproduce the bug and visit:
  
  #   http://icedtea.classpath.org/bugzilla
  
  # The crash happened outside the Java Virtual Machine in native code.
  
  # See problematic frame for where to report the bug.
  
  #
  
  
  
  ---------------  T H R E A D  ---------------
  
  
  
  Current thread (0x00007f8f70141800):  JavaThread "threadpool-14" daemon [_thread_in_native, id=14508, stack(0x00007f8fa73a0000,0x00007f8fa74a1000)]
  
  
  
  siginfo:si_signo=SIGSEGV: si_errno=0, si_code=128 (), si_addr=0x0000000000000000
  
  
  
  Registers:
  
  RAX=0x00007f8f701d2110, RBX=0x00007f8fa65030d0, RCX=0x00007f8fa688efd0, RDX=0x00007f8fa68904b0
  
  RSP=0x00007f8fa749f380, RBP=0x00007f8fa749f3d8, RSI=0x000000000000000c, RDI=0x00007f8f701d2110
  
  R8 =0x0000000000000000, R9 =0x0000000000000000, R10=0x00007f8fc5eb56e0, R11=0x00007f8fc591af50
  
  R12=0x0000000000000000, R13=0x00007f8f701419d8, R14=0x00007f8fa749f578, R15=0x00007f8f70141800
  
  RIP=0x00007f8fa688f060, EFLAGS=0x0000000000010202, CSGSFS=0x0000000000000033, ERR=0x0000000000000000
  
  TRAPNO=0x000000000000000d
  
  
  
  Top of Stack: (sp=0x00007f8fa749f380)
  
  0x00007f8fa749f380:   00007f8fa688f1a5 00007f8fa688ffe5
  
  0x00007f8fa749f390:   00007f8fa6890025 00007f8fa6890065
  
  0x00007f8fa749f3a0:   00007f8fa68900a5 00007f8fa68900e5
  
  0x00007f8fa749f3b0:   00007f8fa6890125 00007f8fa68904b5
  
  0x00007f8fa749f3c0:   00007f8fa6890678 00007f8fa7198f31
  
  0x00007f8fa749f3d0:   0000000000000000 00007f8f70158540
  
  0x00007f8fa749f3e0:   00007f8fa749f468 00007f8fa71966ae
  
  0x00007f8fa749f3f0:   0000000776cfa560 0000000776cfa560

  ...

  Instructions: (pc=0x00007f8fa688f060)
  
  0x00007f8fa688f040:   c4 e3 5d 0c c0 55 c5 e4 5c c8 c5 e4 58 c0 c5 fc
  
  0x00007f8fa688f050:   29 07 c5 fc 29 4f 20 c3 0f 1f 84 00 00 00 00 00
  
  0x00007f8fa688f060:   c5 fc 28 57 40 c5 fc 28 5f 60 c5 ec 5c fb c5 ec
  
  0x00007f8fa688f070:   58 d3 c5 c4 57 3d 26 e0 13 00 c5 ec c6 df be c5 
  
  
  
  Register to memory mapping:
  
  
  
  RAX=0x00007f8f701d2110 is an unknown value
  
  RBX=0x00007f8fa65030d0: av_fft_calc+0 in /usr/local/lib/libavcodec.so.52.123.0 at 0x00007f8fa644d000
  
  RCX=0x00007f8fa688efd0: <offset 0x441fd0="0x441fd0"> in /usr/local/lib/libavcodec.so.52.123.0 at 0x00007f8fa644d000
  
  RDX=0x00007f8fa68904b0: <offset 0x4434b0="0x4434b0"> in /usr/local/lib/libavcodec.so.52.123.0 at 0x00007f8fa644d000
  
  RSP=0x00007f8fa749f380 is pointing into the stack for thread: 0x00007f8f70141800
  
  RBP=0x00007f8fa749f3d8 is pointing into the stack for thread: 0x00007f8f70141800
  
  RSI=0x000000000000000c is an unknown value
  
  RDI=0x00007f8f701d2110 is an unknown value
  
  R8 =0x0000000000000000 is an unknown value
  
  R9 =0x0000000000000000 is an unknown value
  
  R10=0x00007f8fc5eb56e0: <offset 0xe006e0="0xe006e0"> in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so at 0x00007f8fc50b5000
  
  R11=0x00007f8fc591af50: <offset 0x865f50="0x865f50"> in /usr/lib/jvm/java-7-openjdk-amd64/jre/lib/amd64/server/libjvm.so at 0x00007f8fc50b5000
  
  R12=0x0000000000000000 is an unknown value
  
  R13=0x00007f8f701419d8 is an unknown value
  
  R14=0x00007f8fa749f578 is pointing into the stack for thread: 0x00007f8f70141800
  
  R15=0x00007f8f70141800 is a thread
  
  
  
  
  
  Stack: [0x00007f8fa73a0000,0x00007f8fa74a1000],  sp=0x00007f8fa749f380,  free space=1020k
  
  Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
  
  C  [libavcodec.so.52.123.0+0x442060]
  
  </offset></offset></offset></offset>

  This occurs on different physical instances so chances are pretty low it’s hardware issue. Thanks !

• Easily track Events within Matomo Analytics thanks to Matomo Tag Manager

  7 juin 2019, par Matomo Core Team — Analytics Tips

  Easily track Events within Matomo Analytics thanks to Matomo Tag Manager

  Introduction

  In this article we’ll cover what events in Matomo Analytics are ; and how you can easily set them up thanks to Matomo Tag Manager.

  Key concepts within this article

  • Events
  • Quick definition of the Tag Management System
  • Matomo config
  • Creating triggers
  • Variables

  What are events in Matomo Analytics and why are they useful ?

  Events allow you to measure interactions on your website which are not defined by default. With them you can measure clicks on some elements of a page, such as, how visitors are interacting with dropdown menus, media players, scrolling behaviours etc. You can also use them to define goals which make them a key feature in Matomo Analytics. Learn more about tracking events in Matomo.

  You can easily access the Events report in Matomo Analytics by clicking on the Behaviour category :

  

  And you may read the following message and feel a bit frustrated :

  

  “There is no data for this report” is a nice way to say, “Hey, you are tracking just a tiny part of what Matomo Analytics can do for you.”

  Matomo is a great software, but it can’t guess what you want to track.

  In order for Matomo to register those event tracking interactions, you’ll need to explain it by adding a line of code similar to this one when the interaction happens :

   

  _paq.push(['trackEvent', 'Here you enter whatever you want', 'Here too', 'and here also']);

   

  Let’s imagine you want to track a click on an HTML button, your code will look something similar to this at the moment of the interaction :

  Click Me !

  As you can imagine, two main challenges will arise for non developers :

  1. How to access the source code ?
  2. How to define the interaction ?

  Luckily, Matomo Tag Manager makes those steps easy for you. Let’s see how the same tracking is implemented with Matomo Tag Manager.

  A quick definition of what Matomo Tag Manager is

  Matomo Tag Manager lets you manage all your tracking and marketing tags in one easy-to-access place. Please visit this page to learn more about Matomo Tag Manager. In order to start using it, you’ll need to copy/paste a tracking code, named a “container”, within the section of your pages.

  Once the container is on your website, all you need to do is to follow these simple steps :

  1. Add a Matomo Tag.
  2. Assign the condition to fire the tag (what we call the trigger).
  3. Publish your work.
  4. And enjoy

  1 – Add a Matomo Event tracking code

  All you have to do here is click on “CREATE NEW TAG”

  

  Once selected, just mention how you’d like this tag to be named (it is for your internal purpose here so always use an explicit tag name) and the Matomo configuration (the default configuration setting will be fine in most of the cases) :

  

  Then Matomo Tag Manager will ask you the type of tracking you’d like to deploy, in this case, this is an event so select “Event” :

  

  Then all you need is to indicate the values you’d like to push through your event :

  

  To put it in perspective, all we did here through Matomo Tag Manager was implement the equivalent of the following line of code :

  _paq.push(['trackEvent', 'Element interactions', 'Click button', 'Click Me']);

  Let’s now see how can we do this on click code part which we call a trigger.

  2 – Assign the condition to fire the tag

  In order to execute the event we’ll need to define when it will happen. You do this by clicking on Create a new trigger now :

  

  As the interaction we’d like to track is happening when a click occurs, it will be a click trigger, and as our button is not a link, we’ll select All Elements Click :

  

  Once selected you’ll need to be precise on the condition in which the event will be triggered. In this case we do not want to have events pushed every time someone is clicking on something on our website. We only want to track when they click on this specific button. That’s the reason why our trigger is set to fire only when the click occurs on an element which has an id and has the value “cta” :

  Once you click on the green button named CREATE NEW TRIGGER, you validate the tag by clicking on CREATE NEW TAG :

  

  

  Then you can move to the last part.

  3 – Publish your work

  Tag Managers are very powerful as they allow you to easily execute any JavaScript code, CSS or even text content on your websites.

  That’s why when you create your tag it doesn’t go live straight away on your website. In order to do this you need to publish your tag and this is what the “Publish” category is designed for :

  

  After that, click on the second button if you’re confident your tag and trigger are both ready to go live :

  

  4 – Enjoy

  Well done. As your tag is now live, every click made on this button will now be pushed to your Matomo Analytics account within :
  

  1. The visitor log report :

  

  2. The events report :

  

  You may now be asking, “That’s great, but can I collect something more exciting than clicks ?” 

  Of course you can ! This is what the Matomo Tag Manager is all about.

  As long as you can express it through a trigger you can really push whatever you want to Matomo Analytics. You can track scrolling patterns, an element visible on the page like an image, an ad or the time spent on the page. The options are now open to you with Tag Manager.

  Give them a try ! Change the triggers, start playing around with variables and discover that the possibilities are endless.

  Happy analytics,
  Matomo team

• Zlib vs. XZ on 2SF

  21 juillet 2012, par Multimedia Mike — General, psf, saltygme, xz, zlib

  I recently released my Game Music Appreciation website. It allows users to play an enormous range of video game music directly in their browsers. To do this, the site has to host the music. And since I’m a compression bore, I have to know how small I can practically make these music files. I already published the results of my effort to see if XZ could beat RAR (RAR won, but only slightly, and I still went with XZ for the project) on the corpus of Super Nintendo chiptune sets. Next is the corpus of Nintendo DS chiptunes.

  Repacking Nintendo DS 2SF
  The prevailing chiptune format for storing Nintendo DS songs is the .2sf format. This is a subtype of the Portable Sound Format (PSF). The designers had the foresight to build compression directly into the format. Much of payload data in a PSF file is compressed with zlib. Since I already incorporated Embedded XZ into the player project, I decided to try repacking the PSF payload data from zlib -> xz.

  In an effort to not corrupt standards too much, I changed the ’PSF’ file signature (seen in the first 3 bytes of a file) to ’psf’.

  Results
  There are about 900 Nintendo DS games currently represented in my website’s archive. Total size of the original PSF archive, payloads packed with zlib : 2.992 GB. Total size of the same archive with payloads packed as xz : 2.059 GB.

  Using xz vs. zlib saved me nearly a gigabyte of storage. That extra storage doesn’t really impact my hosting plan very much (I have 1/2 TB, which is why I’m so nonchalant about hosting the massive MPlayer Samples Archive). However, smaller individual files translates to a better user experience since the files are faster to download.

  Here is a pretty picture to illustrate the space savings :

  
  
  

  The blue occasionally appears to dip below the orange but the data indicates that xz is always more efficient than zlib. Here’s the raw data (comes in vanilla CSV flavor too).

  Interface Impact
  So the good news for the end user is that the songs are faster to load up front. The downside is that there can be a noticeable delay when changing tracks. Even though all songs are packaged into one file for download, and the entire file is downloaded before playback begins, each song is individually compressed. Thus, changing tracks triggers another decompression operation. I’m toying the possibility of some sort of background process that decompresses song (n+1) while playing song (n) in order to help compensate for this.

  I don’t like the idea of decompressing everything up front because A) it would take even longer to start playing ; and B) it would take a huge amount of memory.

  Corner Case
  There was at least one case in which I found zlib to be better than xz. It looks like zlib’s minimum block size is smaller than xz’s. I think I discovered xz to be unable to compress a few bytes to a block any smaller than about 60-64 bytes while zlib got it down into the teens. However, in those cases, it was more efficient to just leave the data uncompressed anyway.