Project

General

Profile

Actions
Copy link

Optimization #551

open
EL OD

Replace SCLogError by a counter for memory issue and other memcap

Optimization #551: Replace SCLogError by a counter for memory issue and other memcap

Added by Eric Leblond over 13 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
OISF Dev
Target version:
TBD
Effort:
Difficulty:
Label:

Description

Using a SCLogError for memcap or other memory issues can lead to a lot of messages. They should be replaced by some counters.

Subtasks 1 (0 open — 1 closed)

Bug #525: [ERRCODE: SC_ERR_MEM_ALLOC(1)]ClosedEric LeblondActions

Related issues 1 (1 open — 0 closed)

Related to Suricata - Optimization #614: Rate limiting messagesAssignedCommunity TicketActions

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #1

  • Status changed from New to Assigned
  • Assignee set to Eric Leblond

EL Updated by Eric Leblond over 13 years ago Actions
Copy link
 #2

  • Subject changed from Replace SCLlogError by a counter for memory issue and other memcap to Replace SCLogError by a counter for memory issue and other memcap

We've got 145 occurances of 'SCLogError(SC_ERR_MEM_ALLOC' in the code. There is no way to know if a function is not an init function but to read it and understand its call graph. Doing that 145 may result in errors (for sure if I do it).
But even if it is done correctly we will need to have a lot of counters. Or we can just add one : malloc_failed.

On other complementary approach could be to rate limit this error message and use the previously mentioned counter.

What do you think ?

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #3

Rate limiting is something we need regardless, can you open a separate ticket for that?

I'm fine with a single malloc counter. I think we will have review which ones are important, like mallocs at detection time. Maybe you can do a coccinelle search and replace on SCLogError(SC_ERR_MEM_ALLOC and do a trivial change (like add a comment). Then in the pull request we can easily inspect them one by one. Make sense?

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #4

  • Target version changed from 1.4beta2 to 1.4beta3

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #5

  • Target version changed from 1.4beta3 to 1.4rc1

VJ Updated by Victor Julien over 13 years ago Actions
Copy link
 #6

  • Target version changed from 1.4rc1 to 2.0rc2

VJ Updated by Victor Julien about 12 years ago Actions
Copy link
 #7

  • Target version changed from 2.0rc2 to 3.0RC2

VJ Updated by Victor Julien over 10 years ago Actions
Copy link
 #8

  • Target version changed from 3.0RC2 to 70

EL Updated by Eric Leblond over 7 years ago Actions
Copy link
 #9

  • Assignee deleted (Eric Leblond)

VJ Updated by Victor Julien over 7 years ago Actions
Copy link
 #10

  • Status changed from Assigned to New
  • Target version deleted (70)

Needs further thought before starting an implementation.

AH Updated by Andreas Herz almost 7 years ago Actions
Copy link
 #11

  • Assignee set to OISF Dev
  • Target version set to TBD

PA Updated by Philippe Antoine over 2 years ago Actions
Copy link
 #12

Does this ticket still make sense now that SC_ERR_MEM_ALLOC and other error codes are gone @Eric Leblond ?

PA Updated by Philippe Antoine over 2 years ago Actions
Copy link
 #13

  • Tracker changed from Bug to Optimization
Actions
Copy link

Also available in: PDF Atom