Before sending a question to Stack Overflow, take the time to read: http://stackoverflow.com/help/how-to-ask
In particular, you *must* create a *complete* program that shows the problem. See http://stackoverflow.com/help/mcve However, before you think about asking a question on Stack Overflow, please read http://ericlippert.com/2014/03/05/how-to-debug-small-programs and learn how to debug your code (I appreciate you are a step up from the target audience for that article, but there’s lots of good advice for hoary old-timers like me.) Von: [email protected] [mailto:[email protected]] Im Auftrag von Kenneth Mastro Gesendet: Montag, 25. Januar 2016 17:44 An: libmicrohttpd development and user mailinglist <[email protected]> Betreff: Re: [libmicrohttpd] get all post data in a map Sorry.. I don't have time to debug your code for you. If you have a seg fault, do you have a core dump? If so, why not look at it in gdb or some other debugger? Failing that, just use print statements to figure out where the problem is. If you need programming help in general, check out Stack Overflow (as the purpose of this mailing list is to help with MHD). The code you posted really isn't very extensive. It shouldn't be too hard to debug it. If you don't know how to do that, I can pretty much guarantee that you're going to want to step away from MHD and get some more experience in general first. That said, segmentation faults are usually the result of trying to access memory that isn't what you think it is - with an uninitialized pointer or something that got deleted/freed that you didn't intend. I'm not asking the following questions to get the answers to them - like I said, you're going to need to debug your own code - but some things for you to think about: * Where are you storing the map of key/value pairs? Is it in some type of request object you created? (I didn't see where that was created in the code you posted.) * Is the post processor callback being called at all? (Have you verified that?) * If so, do the values ever get inserted into your map? (Have you checked that when you insert them?) * Do you truly understand MHD's 'connection callback' flow - are you creating and destroying objects and assigning pointers when you're supposed to? (If not, make sure you read MHD's documentation and understand what's going on in the tutorials.) Like I said earlier - MHD is great, but POST processing with it is not trivial/easy/simple. You have to understand what's going on in order to use it correctly. Maybe you're trying to run before you can walk... I can promise you that MHD's code works and will not seg-fault internally if you're using it correctly (and it might not even if you screw up). MHD is very solid - the problem is definitely in your code. You need to figure out where the seg fault is - figure out which pointer is messed up and why. That's probably not much help or what you were looking for, but that's the most I can offer you. Hope it helped. Ken On Mon, Jan 25, 2016 at 11:17 AM, rahul bhola <[email protected]<mailto:[email protected]>> wrote: Hi, I followed what you told me in last mail and the browser started to get response even to post messages but i am still on able to access the map data. It shows me seg fault. Most of the codes are almost similar to what i found in example for the site. Can you please look over them once and guide me in the right direction. Here is the link to the same https://gist.github.com/georoot/aff2825e0177cb3cc1ae thanks for helping me out. On Mon, Jan 25, 2016 at 1:30 PM Kenneth Mastro <[email protected]<mailto:[email protected]>> wrote: I'm not sure what the problem is, then.. I thought you said the request 'hangs on'? So that's not the case..? Your server IS responding to the request? You don't need to 'terminate' the post-iterator callback function yourself from inside the callback. It will stop being called when there is no more data to parse. I do basically the same thing you're trying to do - put the post parameters into a map. The callback doesn't get to decide when the post data has been completely processed - that's decided by your server (probably in your connection callback). Maybe you're missing the step where you set the 'data size' pointer to 0 to tell MHD you've absorbed all the data from that chunk of the POST request? The second-to-last parameter in the connection callback is a size_t* that represents the 'upload data size'. You need to set the value to 0 if you absorbed all the data - very probably after you call 'MHD_post_process'. Something like this: if(*uploadDataSize != 0) { // process the post data using MHD's default post-processor - this will call your post-processor-callback function result = MHD_post_process(pointerToYourPostProcessorForThisConnection, uploadData, *uploadDataSize); // tell MHD you're done with all that data *uploadDataSize = 0; } POST data comes in chunks to MHD - so your 'connection callback' will be called repeatedly until the data is complete (or probably if you return MHD_NO, but I'm not sure). So - If you put something like the above snippet in your connection callback, will ultimately be called repeatedly until MHD tells you that 'uploadDataSize' is 0 - that there is no more data to process. After that point, MHD will stop sending you the POST data and your server can do whatever it wants with all the data you've collected. In the snippet you sent, I don't see anything in there that actually CALLS the post processor (I see the create, but not the call to process the data). I'm guessing that's what you're missing. As a side note: MHD is really really great, but using it to process POST data is not trivial. It took me a while to get right. You should at least start with the example in the tutorial and go from there. Hope that helps. Ken On Mon, Jan 25, 2016 at 8:06 AM, rahul bhola <[email protected]<mailto:[email protected]>> wrote: yes every response is just the url. I am still not doing anything with the post data. Just trying to store it in a map. Let me attach gist files for the same here is the code snippets for the same https://gist.github.com/georoot/89394b3a792e9e2d34b2
