Sending int with mq_send - queue

The solution in the post below doesn't work for me. I get error message "Message too long". What can be the problem?
How to send integer with message queue with POSIX API in linux?
If I am correct a pid_t is defined as an int. I have done the following:
struct mq_attr attr;
attr.mq_flags = 0;
attr.mq_maxmsg = 1000;
attr.mq_msgsize = sizeof(pid_t);
mqd_t queue = mq_open(unique_name, O_RDWR|O_CREAT, 0600, &attr);
mqd_t result = mq_send(queue, &pid, sizeof(pid), 0);
I get the following error at compilation at the line of mq_send:
"passing argument 2 of 'mq_send' from incompatible pointer type"
"initialization makes pointer from integer without a cast"

The problem was that I never did mq_unlink.

You probably want to set the maximum message size and queue size with an mq_attr first. See this post for more detail on POSIX queues.

Related

pcap_getnonblock() returns -3

I am quite new to using pcap lib, so please bear with me.
I am trying to use pcap_getnonblock function, the documentation says the following:
pcap_getnonblock() returns the current 'non-blocking' state of
the capture descriptor; it always returns 0 on 'savefiles' . If
there is an error, PCAP_ERROR is returned and errbuf is filled in
with an appropriate error message.
errbuf is assumed to be able to hold at least PCAP_ERRBUF_SIZE
chars.
I got -3 returned and the errbuf is an empty string, I couldn't understand the meaning of such result.
I believe this caused a socket error: 10065.
This problem happened only once and I could not reproduce it, but still it would be great to find its causing to prevent it in future executions.
Thanks in advance.
pcap_getnonblock() can return -3 - that's PCAP_ERROR_NOT_ACTIVATED. Unfortunately, that's not documented; I'll fix that.
Here's a minimal reproducible example that demonstrates this:
#include <pcap/pcap.h>
#include <stdio.h>
int
main(int argc, char **argv)
{
pcap_t *pcap;
char errbuf[PCAP_ERRBUF_SIZE];
if (argc != 2) {
fprintf(stderr, "Usage: this_program <interface_name>\n");
return 1;
}
pcap = pcap_create(argv[1], errbuf);
if (pcap == NULL) {
fprintf(stderr, "this_program: pcap_create(%s) failed: %s\n",
argv[1], errbuf);
return 2;
}
printf("pcap_getnonblock() returns %d on non-activated pcap_t\n",
pcap_getnonblock(pcap, errbuf));
return 0;
}
(yes, that's minimal, as 1) names of interfaces are OS-dependent, so it has to be a command-line argument and 2) if you don't run the program correctly, it should let you know what's happening, so you know what you have to do in order to reproduce the problem).
Perhaps pcap_getnonblock() and pcap_setnonblock() should be changed so that you can set non-blocking mode before activating the pcap_t, so that, when activated, it will be in non-blocking mode. It doesn't work that way currently, however.
I.e., you're allocating a pcap_t with pcap_create(), but you're not activating it with pcap_activate(). You need to do both in order to have a pcap_t on which you can capture.

Trying to match to a typedef value in a receive statement causes "bad node type 44" error message

When I try to match a message in a receive statement I get a "bad node type 44" error message. This happens when the message's type is a typedef. The error message is rather cryptic and doesn't give much insight.
typedef t {
int i
}
init {
chan c = [1] of {t}
t x;
!(c ?? [eval(x)]) // <--- ERROR
}
Note: This may, or may not, be a bug in Spin: apparently, the grammar allows using a structure variable as an argument for eval(), but it does not look like this situation is handled correctly (within the extent of my limited understanding). I would encourage you to contact the maintainers of Promela/Spin and submit your model.
Nevertheless, there is a work-around for the issue you reported (see below).
Contrary to what is reported here:
NAME
eval - predefined unary function to turn an expression into a constant.
SYNTAX
eval( any_expr )
The actual promela grammar for EVAL looks a bit different:
receive : varref '?' recv_args /* normal receive */
| varref '?' '?' recv_args /* random receive */
| varref '?' '<' recv_args '>' /* poll with side-effect */
| varref '?' '?' '<' recv_args '>' /* ditto */
recv_args: recv_arg [ ',' recv_arg ] * | recv_arg '(' recv_args ')'
recv_arg : varref | EVAL '(' varref ')' | [ '-' ] const
varref : name [ '[' any_expr ']' ] [ '.' varref ]
Take-aways:
apparently, eval is allowed to take as argument a structure (because name may be the identifier of a typedef structure [?])
eval can also take as argument a structure field
when one aims to apply message filtering to an entire structure, it can expand the relevant fields of the structure itself
Example:
typedef Message {
int _filter;
int _value;
}
chan inout = [10] of { Message }
active proctype Producer()
{
Message msg;
byte cc = 0;
for (cc: 1 .. 10) {
int id;
select(id: 0..1);
msg._filter = id;
msg._value = cc;
atomic {
printf("Sending: [%d|%d]\n", msg._filter, msg._value);
inout!msg;
}
}
printf("Sender Stops.\n");
}
active proctype Consumer()
{
Message msg;
msg._filter = 0;
bool ignored;
do
:: atomic {
inout??[eval(msg._filter)] ->
inout??eval(msg._filter), msg._value;
printf("Received: [%d|%d]\n", msg._filter, msg._value);
}
:: timeout -> break;
od;
printf("Consumer Stops.\n");
}
simulation output:
~$ spin test.pml
Sending: [1|1]
Sending: [0|2]
Received: [0|2]
Sending: [0|3]
Received: [0|3]
Sending: [0|4]
Received: [0|4]
Sending: [0|5]
Received: [0|5]
Sending: [1|6]
Sending: [0|7]
Received: [0|7]
Sending: [0|8]
Received: [0|8]
Sending: [1|9]
Sending: [1|10]
Sender Stops.
timeout
Consumer Stops.
2 processes created
Generating a verifier does not result in a compilation error:
~$ spin -a test.pml
~$ gcc -o run pan.c
Note: when using both message filtering and message polling (like in your model sample), the fields of the structure that are subject to message filtering should be placed at the beginning of it.
Apparently it's a bug, link to github issue: https://github.com/nimble-code/Spin/issues/17
Update: Bug is now fixed.
Update 2: Bug was actually partially fixed, there are still some edge cases where it's behaving weirdly.
Update 3: As far as I can tell bug looks fixed now. The only downside is that it seems that now there is a strict restriction on what you put in the receive args. They have to match exactly the types declared in the channel. No more partial matches or unrolling struct fields.
My guess is that this error is related to the restrictions that structured types have. One restriction is that they can't be handled as a unit, to assign or compare them one must do it one field at a time.
For example, if one writes: x == y, where x and y are variables of a typedef type, the following error is shown: Error: incomplete structure ref 'x' saw 'operator: =='
Under the hood, when trying to compare the channel's queue to match the eval something is triggered that indicates that the comparison can't be done and then raises the "bad node type" message.

How to get COR_PRF_FUNCTION_ARGUMENT_INFO from COR_PRF_ELT_INFO using GetFunctionEnter3Info function in ICorProfilerInfo3 interface

I'm using CLR profiling API and trying to get arguments info (COR_PRF_FUNCTION_ARGUMENT_INFO) from COR_PRF_ELT_INFO using GetFunctionEnter3Info function.
Below is my code. It seems GetFunctionEnter3Info function is not setting the value for pArgumentInfo. It always has null value. However, the function returns S_OK, which is a success.
I may be missing something. How should I get COR_PRF_FUNCTION_ARGUMENT_INFO from COR_PRF_ELT_INFO ?
PROFILER_STUB EnterStub(FunctionIDOrClientID functionId, COR_PRF_ELT_INFO eltInfo)
{
COR_PRF_FRAME_INFO *pFrameInfo = 0;
ULONG *pcbArgumentInfo = 0;
COR_PRF_FUNCTION_ARGUMENT_INFO *pArgumentInfo = NULL;
corProfilerInfo->GetFunctionEnter3Info(functionId.functionID, eltInfo, pFrameInfo, pcbArgumentInfo, pArgumentInfo);
if(pArgumentInfo) {
//
}
}
It is a little bit tricky,
By msdn doc:
pcbArgumentInfo
[in, out] A pointer to the total size, in bytes, of the COR_PRF_FUNCTION_ARGUMENT_INFO structure (plus any additional COR_PRF_FUNCTION_ARGUMENT_RANGE structures for the argument ranges pointed to by pArgumentInfo). If the specified size is not enough, ERROR_INSUFFICIENT_BUFFER is returned and the expected size is stored in pcbArgumentInfo. To call GetFunctionEnter3Info just to retrieve the expected value for *pcbArgumentInfo, set *pcbArgumentInfo=0 and pArgumentInfo=NULL
In other words, you have a single COR_PRF_FUNCTION_ARGUMENT_INFO structure, which references multiple COR_PRF_FUNCTION_ARGUMENT_RANGE.
First of all, get a number of bytes of pcbArgumentInfo, after that allocate bytes and pass the pointer to GetFunctionEnter3Info as COR_PRF_FUNCTION_ARGUMENT_INFO.
Here is an example
PROFILER_STUB EnterStub(FunctionIDOrClientID functionId, COR_PRF_ELT_INFO eltInfo)
{
ULONG pcbArgumentInfo = 0;
COR_PRF_FRAME_INFO frameInfo;
corProfilerInfo3->GetFunctionEnter3Info(functionIDOrClientID.functionID, eltInfo, &frameInfo, &pcbArgumentInfo, NULL);
char* pArgumentInfo = new char[pcbArgumentInfo];
corProfilerInfo3->GetFunctionEnter3Info(functionIDOrClientID.functionID, eltInfo, &frameInfo, &pcbArgumentInfo, (COR_PRF_FUNCTION_ARGUMENT_INFO*)pArgumentInfo);
COR_PRF_FUNCTION_ARGUMENT_INFO* ptr = (COR_PRF_FUNCTION_ARGUMENT_INFO*)pArgumentInfo;
}
To access the second argument info block of COR_PRF_FUNCTION_ARGUMENT_RANGE use
prt->ranges[1]
The number of blocks is written in ptr->numRanges

osip_message_to_str fails on a message I created using the message/parser functions

I'm trying to receive an invite message and then reply with 100 trying and/or 180 ringing to the same client. I'd like to use only the parser from libosip2.
So when I try to osip_message_to_str so I have a buffer to send back, it always fails with -2.
I tried cloning all the fields I thought it would make sense. But still having the same issue.
If I try to osip_message_to_str on the message I received, it works well.
parser_init();
osip_message_t *request = received_buffer(buffer); // the message is received properly from the buffer
osip_message_t *response;
int i = osip_message_init(&response);
if (i != 0) {
fprintf(stderr, "cannot allocate\n");
return -1;
}
osip_message_set_version(response, strdup("SIP/2.0"));
osip_message_set_status_code(response, 100);
osip_from_clone(request->from, &response->from);
osip_to_clone(request->to, &response->to); /* include the tag! */
osip_call_id_clone(request->call_id, &response->call_id);
osip_contact_t *contact = nullptr;
osip_message_get_contact(response, 0, &contact);
osip_uri_clone(osip_contact_get_url(contact), &response->req_uri);
osip_cseq_clone(request->cseq, &(response->cseq));
char *dest = NULL;
size_t length = 0;
i = osip_message_to_str(response, &dest, &length);
if (i != 0) {
fprintf(stderr, "resp cannot get printable message %d\n", i);
return -1;
}
fprintf(stdout, "message:\n%s\n", dest);
I expect to be able to print a response message.
From libosip2, file osip_port.h, the error return code -2 means bad parameter:
#define OSIP_BADPARAMETER -2
The first line of an answer is something like this: "SIP/2.0 100 Trying".
In your code, you are setting correctly both "SIP/2.0" and "100". However, you forgot the reason phrase. For "100", obviously, the string should be "Trying". Thus, a complete first line of a response should be done with:
osip_message_set_version(response, osip_strdup("SIP/2.0"));
osip_message_set_status_code(response, 100);
//ADD THIS
osip_message_set_reason_phrase (answer, osip_strdup("Trying");
The above will fix the first error, but there looks to be more. You are using "osip_message_get_contact" to retrieve a contact from the response. But there is none. In order to set a contact, you need to search for your IP address, port number, and parameters you want to add. Something like this is advised:
osip_message_set_contact (response, "<sip:192.168.1.10:5678;ob>");
The above API will parse the string as a Contact header and add it to the response.
To make it clear (as you have used it), "response->req_uri" is empty for a response. It means "Request-URI" which is only for request.
If you wish a complete response, you will also need to copy all the "Via" headers:
{
osip_list_iterator_t it;
osip_via_t *via = (osip_via_t *) osip_list_get_first (&request->vias, &it);
while (via != NULL) {
osip_via_t *via2;
i = osip_via_clone (via, &via2);
if (i != 0) {
osip_message_free (response);
return i;
}
osip_list_add (&response->vias, via2, -1);
via = (osip_via_t *) osip_list_get_next (&it);
}
}
NOTE: use osip_strdup instead of strdup for any osip allocation to make your code more portable.
osip_message_to_str should work then!
For more precise code, feel free to have a look at my exosip2 code here. It will certainly help you for the next question you will have!

Causing a deliberate DEP error

In short what I want to do is be able to cause a Data Execution Prevention (DEP) error at will.
This is specifically on XP SP3 machines. I'd like it so that when I run a script or small program it brings up the XP DEP error box.
Would I be right in thinking the simplest way to do that is with some sort of script or program? I know DEP is used to prevent buffer overflow attacks but i'd rather not risk any
malicious code being used.
Can anybody suggest anything to get me on the right lines?
The simplest way is to allocate memory without the executable attribute and jump to the address allocated.
This can be done with the following code.
void Code(){
return;
}
void GenerateDepError(){
// Allocate data area
PVOID pMem = VirtualAlloc( NULL, 0x100,
MEM_COMMIT | MEM_RESERVE, PAGE_READWRITE );
// Copy a function into data area
for( DWORD i = 0; i < 0x100; i++ ){
((char*)pMem)[i] = ((char*)Code)[i];
}
// Consider the memory area as a function.
void (*dep_trigger)() = (void (*)())pMem;
// Invoke the function. This should cause DEP error if DEP is ON.
dep_trigger();
// If it returns without error this message will be displayed.
printf("No error on dep_trigger()\n");
}
int main( int argc, char** argv ){
GenerateDepError();
return 0;
}