af-packet: fix livedev packets counter

Packets counter is incremented in AFPDumpCounters and it was
also incremented during packet reading. The result was a value
that is twice the expected result.

Spotted-by: Victor Julien <victor@inliniac.net>
capture: use 64 bits counters

Some of the packets counters were using a 32bit integer. Given the
bandwidth that is often seen, this is not a good idea. This patch
switches to 64bit counter.
lock profiling: fix memory leak

If lock profiling was compiled in, but disabled in the config a
serious memory leak condition was triggered.

Valgrind output:

==11169== 9,091,248 bytes in 189,401 blocks are definitely lost in loss record 564 of 564
==11169==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11169==    by 0xABC44C: LockRecordAdd (util-profiling-locks.c:112)
==11169==    by 0xABC950: SCProfilingAddPacketLocks (util-profiling-locks.c:141)
==11169==    by 0xA04CD5: TmThreadsSlotVarRun (tm-threads.c:562)
==11169==    by 0x958793: TmThreadsSlotProcessPkt (tm-threads.h:142)
==11169==    by 0x9599C3: PcapFileCallbackLoop (source-pcap-file.c:172)
==11169==    by 0x56FC130: ??? (in /usr/lib/x86_64-linux-gnu/libpcap.so.1.4.0)
==11169==    by 0x959D24: ReceivePcapFileLoop (source-pcap-file.c:210)
==11169==    by 0xA05B9E: TmThreadsSlotPktAcqLoop (tm-threads.c:703)
==11169==    by 0x6155F6D: start_thread (pthread_create.c:311)
==11169==    by 0x6E399CC: clone (clone.S:113)
profiling: fix memory leak

For packets that were freed, not recycled, profiling memory wasn't
freed:

==15745== 13,312 bytes in 8 blocks are definitely lost in loss record 611 of 615
==15745==    at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15745==    by 0xA190D5: SCProfilePacketStart (util-profiling.c:963)
==15745==    by 0x4E4345: PacketGetFromAlloc (decode.c:134)
==15745==    by 0x83FE75: FlowForceReassemblyPseudoPacketGet (flow-timeout.c:276)
==15745==    by 0x8413BF: FlowForceReassemblyForHash (flow-timeout.c:588)
==15745==    by 0x841897: FlowForceReassembly (flow-timeout.c:716)
==15745==    by 0x9540F6: main (suricata.c:2296)
==15745==
==15745== 14,976 bytes in 9 blocks are definitely lost in loss record 612 of 615
==15745==    at 0x4C2C494: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15745==    by 0xA190D5: SCProfilePacketStart (util-profiling.c:963)
==15745==    by 0x4E4345: PacketGetFromAlloc (decode.c:134)
==15745==    by 0x83FE75: FlowForceReassemblyPseudoPacketGet (flow-timeout.c:276)
==15745==    by 0x841508: FlowForceReassemblyForHash (flow-timeout.c:620)
==15745==    by 0x841897: FlowForceReassembly (flow-timeout.c:716)
==15745==    by 0x9540F6: main (suricata.c:2296)

This patch addresses that.
lua: fix minor memory leak

The full path of the script names is stored in a buffer that wasn't
freed at exit.

==24195== 41 bytes in 1 blocks are definitely lost in loss record 300 of 613
==24195==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24195==    by 0x565D06: DetectLoadCompleteSigPath (detect.c:251)
==24195==    by 0x7CABE8: DetectLuajitParse (detect-luajit.c:595)
==24195==    by 0x7CD2AE: DetectLuajitSetup (detect-luajit.c:827)
==24195==    by 0x7DC273: SigParseOptions (detect-parse.c:547)
==24195==    by 0x7DDC75: SigParse (detect-parse.c:856)
==24195==    by 0x7E1C2B: SigInitHelper (detect-parse.c:1336)
==24195==    by 0x7E2968: SigInit (detect-parse.c:1559)
==24195==    by 0x7E37B1: DetectEngineAppendSig (detect-parse.c:1831)
==24195==    by 0x566D17: DetectLoadSigFile (detect.c:335)
==24195==    by 0x567636: SigLoadSignatures (detect.c:423)
==24195==    by 0x951A97: LoadSignatures (suricata.c:1816)

This patch frees the buffer.
Fix memory leak in proto - name mapping

==15745== 3 bytes in 1 blocks are definitely lost in loss record 5 of 615
==15745==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==15745==    by 0x71858C1: strdup (strdup.c:42)
==15745==    by 0xA20814: SCProtoNameInit (util-proto-name.c:75)
==15745==    by 0x952D1B: PostConfLoadedSetup (suricata.c:1983)
==15745==    by 0x9537CD: main (suricata.c:2112)

Also, clean up and add a check to make sure it's initialized only once.
pool: on Init() error, properly clean up

In the stream engine, Init() can fail if the memcap is reached. In this
case the segment was not freed by PoolGet:

==8600== Thread 1:
==8600== 70,480 bytes in 1,762 blocks are definitely lost in loss record 611 of 612
==8600==    at 0x4C2A2DB: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==8600==    by 0x914CC8: TcpSegmentPoolAlloc (stream-tcp-reassemble.c:166)
==8600==    by 0xA0D315: PoolGet (util-pool.c:297)
==8600==    by 0x9302CD: StreamTcpGetSegment (stream-tcp-reassemble.c:3768)
==8600==    by 0x921FE8: StreamTcpReassembleHandleSegmentHandleData (stream-tcp-reassemble.c:1873)
==8600==    by 0x92EEDA: StreamTcpReassembleHandleSegment (stream-tcp-reassemble.c:3584)
==8600==    by 0x8D3BB1: HandleEstablishedPacketToServer (stream-tcp.c:1969)
==8600==    by 0x8D7F98: StreamTcpPacketStateEstablished (stream-tcp.c:2323)
==8600==    by 0x8F13B8: StreamTcpPacket (stream-tcp.c:4243)
==8600==    by 0x8F2537: StreamTcp (stream-tcp.c:4485)
==8600==    by 0x95DFBB: TmThreadsSlotVarRun (tm-threads.c:559)
==8600==    by 0x8BE60D: TmThreadsSlotProcessPkt (tm-threads.h:142)

tcp.segment_memcap_drop   | PcapFile                  | 1762

This patch fixes PoolGet to both Cleanup and Free the Alloc'd data in
case Init fails.
unittest: fix mutex unlock w/o a lock

Fixes an error in a test. SCMutexUnlock was called w/o a prior
SCMutexLock.