{"schema":"libjg2-1", "vpath":"/git/", "avatar":"/git/avatar/", "alang":"", "gen_ut":1713578601, "reponame":"libwebsockets", "desc":"libwebsockets lightweight C networking library", "owner": { "name": "Andy Green", "email": "andy@warmcat.com", "md5": "c50933ca2aa61e0fe2c43d46bb6b59cb" },"url":"https://libwebsockets.org/repo/libwebsockets", "f":3, "items": [ {"schema":"libjg2-1", "cid":"52e001f60091f8de92d283dd1523bcf0", "oid":{ "oid": "f28a45246e7ea479718ddba5e80deb355b23f5f3", "alias": [ "refs/heads/main"]},"blobname": "READMEs/README.problems.md", "blob": "Debugging problems\n\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\u003d\n\nCheck it's still a problem with latest lws\n------------------------------------------\n\nOlder versions of lws don't attract any new work after they are released\n(see [the release policy](https://libwebsockets.org/git/libwebsockets/tree/READMEs/README.release-policy.md) for details);\nfor a while they will get backported bugfixes but that's it.\n\nAll new work and bugfixes happen on `main` branch.\n\nOld, old versions may be convenient for you to use for some reason. But unless\nyou pay for support or have contributed work to lws so we feel we owe you some\nconsideration, nobody else has any reason to particularly care about solving\nissues on ancient versions. Whereas if the problem exists on `main`, and can be\nreproduced by developers, it usually gets attention, often immediately.\n\nIf the problem doesn't exist on `main`, you can either use `main` or check also\nthe -stable branch of the last released version to see if it was already solved\nthere.\n\nLibrary is a component\n----------------------\n\nAs a library, lws is always just a component in a bigger application.\n\nWhen users have a problem involving lws, what is happening in the bigger\napplication is usually critical to understand what is going on (and where the\nsolution lies). Sometimes access to the remote peer like server or client is also\nnecessary to provoke the symptom. Sometimes, the problem is in lws, but\nsometimes the problem is not in lws but in these other pieces.\n\nMany users are able to share their sources, but others decide not to, for\npresumed \u0022commercial advantage\u0022 or whatever. (In any event, it can be painful\nlooking through large chunks of someone else's sources for problems when that\nis not the library author's responsibility.)\n\nThis makes answering questions like \u0022what is wrong with my code I am not\ngoing to show you?\u0022 or even \u0022what is wrong with my code?\u0022 very difficult.\n\nEven if it's clear there is a problem somewhere, it cannot be understood or\nreproduced by anyone else if it needs user code that isn't provided.\n\nThe biggest question is, \u0022is this an lws problem actually\u0022? To solve that\nthe best solution is to strip out all or as much user code as possible,\nand see if the problem is still coming.\n\n\nUse the test apps / minimal examples as sanity checks\n-----------------------------------------------------\n\nThe test server and client, and any more specifically relevant minimal example\n are extremely useful for sanity checks and debugging guidance.\n\n - **test apps work on your platform**, then either\n - your user code is broken, align it to how the test apps work, or,\n - something from your code is required to show an lws problem, provide a\n minimal patch on a test app so it can be reproduced\n \n - **test apps break on your platform**, but work on, eg, x86_64, either\n - toolchain or platform-specific (eg, OS) issue, or\n - lws platform support issue\n\n - **test apps break everywhere**\n - sounds like lws problem, info to reproduce and / or a patch is appreciated\n","s":{"c":1713578601,"u": 885}} ],"g": 2598,"chitpc": 0,"ehitpc": 0,"indexed":0 , "ab": 1, "si": 0, "db":0, "di":0, "sat":0, "lfc": "0000"}